XPDAY - Martin Fowler - Keynote - Tuesday 2nd December 2003

Martin Fowler started controversially by announcing that he was a bit sick and tired the Agile world and process methodologies. He used book writing as an example and posed the question: When writing a book, do you do an outline first and then get steadily more detailed? OR Do you just muck in and get busy writing detailed sections and string them all together later? Both methods are 'successful' and merely the personal styles of two different authors. How do you objectively measure the success of the outcome of either of these methods? Isn't it completely subjective? To what do you compare or measure? [Ant - Here I would suggest that perhaps setting your own success criteria is enough providing you do so before you set out to do the work].

Martin is more interested in knowing what makes good software design and how to achieve good software design. SWEBOK (SoftWare Engineers Body of Knowledge) is attempting to define what a software engineer should be knowledgeable about. What would a software university curriculum look like? Analysis, Construction, Design, Testing, etc.

The practice and science of Engineering separates design and construction. Agile, especially XP, does not. Agile advocates doing design and construction together so that each informs the other [Ant - this is only possible because the only cost of building code is man hours and not materials. If physical construction was 'Refactorable' would we engineer and build together too?] Design can be an evolutionary process. UNIX is an example of successful evolutionary design [Ant - although, is the success of UNIX due to the fact that it's free, therefore there is a pretty natural incentive to adopt and grow it or is the success of an evolutionary design that draws people to it?]. Testing, refactoring and continuous integration allows evolutionary design to happen. XP has these three factors that enables evolutionary design to converge.

Only design for the current set of requirements. Future proofing or anticipatory capability isn't so good because extra features and code complicates the system, thus crippling future efforts to adapt and extend the system later. Keeping it simple will enable evolution.

Evolutionary design can work because there are people on the team, willing and able to do it. Teaching design is about showing others how to see problems first. Then over time and apprenticeship, the art of making solutions to the problems can be learned.

You can tell when evolutionary design is happening because the team is motivated, code is being thrown away and the team can freely say 'this isn't working, lets change it'.