Technology Talk
For me, the word 'extreme' conjures up images of seemingly suicidal skiers hurling themselves off Alpine precipices, hooded teenagers trying to skateboard down the handrails in shopping centres, and canoeists battling a cauldron of white-water through a sheer-faced ravine. Although we often brand such antics as crazy, mad or just plain stupid, there is no doubt that the participants gain a certain amount of credibility from their antics - there is definitely something 'cool' about being able to perform such tricks. What is the relevance of this observation? Read on.
Over recent years, much has been done to define software development as an engineering discipline - a profession. Many would argue that this happened years ago, but in comparison with other fields such as electronics or structural engineering, it is my opinion that there is still considerable work to be done.
Typically, building a software system requires a variety of different skills and involves a number of different processes. Many of these processes often rely on judgment, experience and, to a lesser extent, luck. In contrast, there is little place for such a haphazard approach to engineering when designing a bridge or an airliner - this is largely because encountering a General Protection Fault at 35,000 feet has an altogether different set of repercussions.
There are many reasons for this, including the economics of complexity. The Windows XP Operating System is made up of 40 million lines of code, and as with most software, the vast majority of these will have been typed and forgotten by an entirely professional and responsible developer without a second thought. In a typical project, it does not make commercial sense for each of these lines to be analysed and tested independently, and even if such controls were in place, this would not prevent problems from arising as the discrete pieces are progressively combined into larger and larger components.
As software becomes more complex, our approach to building systems is evolving to minimise the problems likely to be caused by these compromises - in a similar way as the mechanical engineers use highly-developed empirical methods to assist in the design, analysis and testing of structures. In software engineering, the well-trodden requirements analysis/systems design/implementation/testing process is being refined using techniques such as formal modelling, compositional re-use, performance profiling, and so on. Year-by-year, more and more such techniques make the transition from academia to commercial use, and the software engineering process becomes more empirical, measurable and efficient. As a result, fewer aspects of the software engineering process are left to chance.
Over the last few years, we have seen a 'new kid on the block' in this field Extreme Programming (XP).The proponents of this radical methodology claim it provides revolutionary advantages to the customer, developer, and user. Although hoods and skateboards are optional, a careful analysis of their message could easily be mistaken for an attempt to make software development 'cool' rather than allow it to continue its progression towards an empirical, measurable process.
The vast majority of the goals of Extreme Programming are valid and wholly worthwhile, although few, if any, are new. Point-by-point, the 'extremos' (their term, not mine) work through the benchmark software development process and propose alternative approaches which are often in diametric opposition to commonly accepted wisdom.
The proposition of a new approach is refreshing, and a lot can be gained from many of the techniques proposed. It is, however, important not to get carried away by the 'extreme' elements, especially when they go against good engineering discipline. Skiing, canoeing and skateboarding have little to contribute to a sound, efficient and commercial software engineering process.