I'm not actually going to write up Martin's keynote, because someone else has already done a much better job of it than I would have.
Instead, I want to try to tie together three sessions at OOPSLA.
On one panel Dave Ungar (one of the inventors of Self amongst other brilliant achievements) said something along the lines of "a breakthrough idea is one that challenges your most deeply held beliefs."
In Martin Fowler's keynote, near the end he mused "does good design even matter?" (not the sort of thing you often hear him say). I don't know if he'd been influenced by Dave Ungar's comment.
In another panel, Kent Beck mentioned some disapproval about Martin's remark.
It got me thinking - Kent Beck has popularised some ideas that were breakthrough ideas as far as I'm concerned - e.g. pair programming - I was sure I wouldn't like it - my deeply held belief was that I worked best by myself - now proven wrong. Test first development - I was sure you had to write the code first then test it, and more sophisticated TDD - I was sure test first development was (only) about testing before really doing TDD and finding out that it wasn't (See Dan North's article for a good treatment of this).
So - maybe, just maybe, Martin's off-the-cuff (and slightly off-the-wall) remark might turn into a breakthrough idea some day. Maybe what we currently think of as Good Design isn't really. It's certainly one of my most deeply held beliefs that Good Design matters a great deal.
However, the results of Scrapheap challenge have challenged my assumptions about what good design is. The best solutions were in some ways elegant and simple; I think you could say they were well designed - but they weren't what I would have thought "good design" would look like before the workshop.
At OOPSLA 2005, a video of Guy Steeles' keynote from OOPSLA 98 was shown at the lunch times. It was a beautifully, and cleverly crafted talk. In his talk he defines all words over one syllable (in terms of words of one syllable or words that he's already defined). His talk is about language design - whether languages should be "small" or "large" - and describes how languages should be designed to grow.
It's in the context of Java, but it's a bit ironic that Java is so limited in the ways in which it can be extended by users, and in how large it is compared to really well designed languages like Smalltalk or Self (meow - that sounds more harsh than I mean). Guy Steele identified a couple a features of Java that he wanted to add - generics (now in Java) and operator overloading. It's certainly worth watching, even by people not involved with software, for it's wonderfully crafted presentation.
Here's a written version of the talk.
The keynote by Robert Hass (ex United States Poet Laureate) had some interesting points. He claimed that people need to feel safe in order to be creative. I think this is absolutely correct. I think this is why teams where the project manager is skilled in shielding the team from undue pressure, and fixing political and administrative stresses so the developers don't even notice them, are the most productive teams.
He said that studies have shown that there is not much correlation between creativity and IQ. I find that very intruiging. I think I often think of people who are more creative than me as also being more intelligent. Of course, I might be correct even if there is no statistical correlation!
David Reed gave a presentation about Croquet and it's TeaTime model. I think it was inspired by Douglas Adam's The long dark long tea time of the soul but he didn't cite the book :-)
One of the most interesting programming language approaches that I've seen in the last 10 years (in fact, I think the only new one in that time - comments please if you can think of others) is the work of Jonathan Edwards; a language called subtext. He presented a very early version at last year's OOPSLA and has developed the idea further. I can't really describe it well - it's based on a model that Nat Pryce compared to excel. At first I didn't get what he meant - it's got nothing to do with the grid nature of excel. It's the fact that it's always evaluated - there's no separate edit and run time. State changes are handled by having hypothetical future states - you can see what the state of objects are now and how they were in the past and how they would be in the future if you executed subtext's equivalent of procedures. I can't really describe it very well - have a look for yourself - it's different to anything else that I've seen.
Here are some of the things that people said on this panel (paraphrased in some cases):
Grady Booch: I can't be held responsible for the stupid ways UML is sometimes used.
Grady Booch: I often throw models away but tend not to throw away the source code.
Grady Booch: 90% of software developers don't read books - and worse, don't read other people's code.
Yourdon: 10% of failures are caused by technical reasons, e.g. (lack of) performance, requirements, testing. 90% of failures are caused by bad project management or "politics".
From the notes that I took it looks like Grady Booch said more than the other panelists but that's not the case; just what I chose to make notes of.
Nat and I ran the Scrapheap Challenge workshop yesterday. Participants were paired up (changing who they paired with for each challenge), given challenges to implement (using any technology they want - including using anything they can find on the scrapheap that we call the internet). There will be proper write-ups, including source code of the solutions, linked from the Scrapheap Challenge wiki page - here I just want to give a flavour of how it was.
One of the challenges was chosen because it's a tool that I want when I'm working as an XP coach. This challenge was to build an "integrationometer" - a dial that shows how far away from the team's code I am - i.e. how many lines of incoming and outgoing changes I've got compared to what's checked in. I want such a tool to remind people that if they don't check in frequently, they are getting further and further from the team's code base and will not only have a hard time themselves updating (and merging as necessary) but are also going to make life harder for everyone else if they check in after a long time when they've got lots of changes. This isn't my idea - I can't remember who suggested it - I think it was Oli Bye - but if it wasn't then please add a comment.
The participants were fantastic - they produced solutions to some tricky challenges (like the "integrationometer") within just 90 minutes per challenge. The approaches were very creative - some are written up by one of the participants during the workshop (challenges one, two and three and even the recap. Hopefully the other solutions will be posted soon.)
Everyone seemed to enjoy the workshop and I think we all learnt lots. The technologies used included JavaScript (using greasemonkey), Python and lots of unix style tools (e.g. grep, sed). We didn't put any constraints on what people used, but strangely no successful solution used a statically (and manifestly) typed language like Java or C#. I guess if you're in a hurry you just don't have time to type all those type declarations :-)
I'm currently at OOPSLA 2005 where I'll be co-presenting the Scrapheap Challenge (oopsla page) workshop with Nat Pryce.
I've been lucky enough to go to lots of conferences in the last few years. The locations have sometimes provided suprises.
The best weather was in Sheffield (north of England). (OOPSLA this year is in San Diego - where it's currently raining.)
The best scenery was in Garmisch-Partenkirchen, Germany (much better than Vancouver).
I'll be writing up notes from OOPSLA over the next few days - if I stop shivering from the cold and wet weather (or it improves as everyone claims it will)!
In this third article in the series about using version control, I'll cover using version control in a team, which is where it becomes one of the most essential tools to get to grips with in software development.
In the first article, I was trying to write a small program in the jPoetry.NET language. I had written this:
I walked around by myself for a bit, feeling a bit lonely,
like a cloud floating over the vales and hills,
then suddenly saw some flowers;
they were cool.
Now, my boss is worried that I have slipped behind schedule (and hasn't read The Mythical Man Month), so she assigns Billy Wordsvalue to help me. Fortunately, he's pretty good at the syntax and semantics of this programming language and we get on with our work. Billy and I are not pair poetry writing (we haven't read Extreme Programming Explained, or Pair Programming). We work on separate computers with our code checked out on our local hard disks.
In order to check in my changes, when I'm working in a team do the following sequence:
1) run all tests
2) update, including doing any manual integration needed if there are conflicting updates (more about this later)
3) run all tests again if there were any updates. I like to run the tests before updating (i.e. step 1) because if the tests fail after I've updated then I want to be sure that the problem is because of something I've updated rather than because the tests would have failed even without an update. The tests have to run quickly if you want to check-in frequently.
4) I like to check through what I'm about to commit because I've got a terrible memory, and might leave some dodgy System.out, or worse, in the code.
5) update again - in case someone has checked-in while I've been running the tests and reading through the changes (having fast version control system is also important when checking in frequently.
6) if there were no incoming changes then commit1, otherwise start from (2) again
1I like the people making the check in to include their initials in the check in comment, so it's easy to tell who to ask if you don't understand some code or changes to some code. You can't rely on the login details when people are pair programming or when you have people swapping machines/logins as happens on many Agile projects.
Billy edits the code as follows:
I walked around by myself for a bit, feeling a bit lonely,
like a cloud that floats on high o'er vales and hills,
then suddenly saw some flowers;
they were cool.
He goes through steps 1-6 and commits his changes (he finds that there are no incoming changes so his check in is easy). At the same time, I've been working and have edited the code as follows:
I walked around by myself for a bit, feeling a bit lonely,
like a cloud floating over the vales and hills,
then suddenly saw some flowers;
by a puddle,
they were cool.
Now I am ready to check in, so I do the steps:
1) "run all tests" - they pass
2) "update, including doing any manual integration needed" - I do an update, and subversion merges Billy's changes into my file, in this case without any conflicts as we have changed different lines. In practice, even on teams of a dozen developers, you don't get many conflicts. The result is:
I walked around by myself for a bit, feeling a bit lonely,
like a cloud that floats on high o'er vales and hills,
then suddenly saw some flowers;
by a puddle,
they were cool.
3) "run all tests again" - they pass
4) I check to see what changes I've made. Because I've done an update, the only changes shown are the ones I've made, not the changes that Billy made.
5) "update again" - Billy hasn't checked in since (1) so there are no more incoming changes
6) "if there were no incoming changes then commit" - so I commit.
Meanwhile, Billy has continued to work. He continues to edit:
I wandered lonely as a cloud
that floats on high o'er vales and hills,
then suddenly saw some flowers;
they were cool.
He goes through steps 1-6 again. The result of his update and check in leaves the poem as:
I wandered lonely as a cloud
that floats on high o'er vales and hills,
then suddenly saw some flowers;
by a puddle,
they were cool.
I edit:
I walked around by myself for a bit, feeling like a lost slug,
or a cloud that floats on high o'er vales and hills,
then suddenly saw some flowers;
by a puddle,
they were cool.
Now when I try to update, I get a warning that there is a conflict. Billy and I have both changed the first two lines. In cases like this, subversion can't work out how to merge the changes itself - it takes understanding to resolve the conflict. I manually resolve the conflicts and end up with:
I wandered around, feeling like a lost slug, lonely as a cloud
that floats on high o'er vales and hills,
then suddenly saw some flowers;
by a puddle,
they were cool.
which I think merges the best of Billy's work with mine. I tell subversion that the merge conflict is resolved.
I continue with steps (3)-(6) and check in.
We continue to work and end up with:
Mary had a little lamb,
its fleece was white as snow,
everywhere that Mary went,
the lamb was sure to go.
It's a funny old world.