I went to the XPDay conference last December where Martin Fowler gave one of the keynotes. I enjoyed the conference as a whole very much. While there were some XP zealots, I also found plenty of more rounded views which were of great interest (to me).
Martin’s talk was interesting and I took some notes which I have been meaning to write up.
There was nary a power point slide in site as he strode around the room talking to us as he went – rather like your archetypal absent minded professor. He did refer back to previous conference talks he has given – “that was when I used to plan my talks as opposed to just give a generic title and talk about my current preoccupations!”.
He started his talk by saying that he was getting a bit tired of XP (and yes he was being a bit provocative!).
He compared software development with book writing, and concluded that the process of development varies legitimately because of who is doing it rather than what they are doing (his style vs. Steve McConnell, both of whom are successful authors). Martin thinks about something and then writes a complete section on that topic. He repeats this process, and then starts refactoring the topics, out of which comes his book. Steve apparently refines an outline view down to a very detailed level for the whole book. Then he fleshes out each detailed point with a few paragraphs and is done. Two very different ways of going about it. When asked if he would co-author a book with Steve he was doubtful because their styles are so different, whereas he has successfully co-authored with Kent Beck).
How do you measure the value of software? This is frequently rather difficult since reducing some business process down from 2 days to 45 minutes is down to a number of factors, not just the software that helped enable it. Software methodologies tend to be very difficult to compare and are not really measurable. Thus relative arguments are frequently founded on sand (there is a lot of heat in online discussions to very little benefit).
So, what makes good software design? He mentioned Eric Raymond’s The Art of Unix Programming as discussing what people have done to succeed as opposed to laying out what they should do to succeed.
In his view, the XP community consider design and programming to overlap to a huge degree (growing out of Smalltalk/Lisp/Unix world and experience). Others have the experience that programming without design leads to huge problems, and therefore conclude that the XP way can’t work.
Can evolutionary design work? Absolutely, and Unix is a prime example.
Martin discussed this topic in “Is Design Dead?”. He now considers that article fine up to a point, but he realised that he had missed a major issue to do with people. This was highlighted for him by Enrico Zaninotto during XP2002 that you need something to make the process converge. Various XP practices influence this: test driven development, refactoring and continuous integration make evolutionary design possible. Things like YAGNI seem counter intuitive, but anticipatory design is seldom correct, it adds complexity, and the “cost of carry” is frequently large. Unix worked by releasing early and often, and building simply and evolving.
In Martin’s current view, the most important factor in getting evolutionary design to work is to have people on the team with the will and the ability to “make things converge”. Ability means that people recognise imperfections in a system (this is more important than knowing how to solve them – you can ask for help with that). Will means looking at what’s going on and have an active desire to fix it, persuade others etc. Thus motivation of a project team is a huge factor. You get problems if you don’t have people poking around looking into things and how to make them converge.
If design and programming happen together, how can a manager tell that any design is actually being done? The manager needs to get a sense of “do people care?” and “is action happening?”. An important clue is that code being thrown away indicates design is happening. Next clue is the sense of the team dynamics or motivation.
And that was it. I certainly found it very interesting.
