Too Young to Die, Too Old for Programming?

“Too Old to Rock ‘n’ Roll: Too Young to Die!” is a music album released in 1976 by Jethro Tull. Sometimes I feel disconnected with the current evolution of software development. I have the impression that part of the software development community advances ignoring or rejecting the past. Although the Agile Manifesto declares “while there is value in the items on the right, we value the items on the left more”, it seems that people are denying value to previous approaches (“items on the right “) or trying to put an “agile” label on them, as if it was the only way to be accepted. Web material about the fact that modelling is useless or questions about the need for IDE caused the same impression. Ruby on Rails is a great idea, but it is a step beyond for me if the only development tool you can use is a text editor.

The problems of software development remain the same and the proposed solutions share similarities. I will use as an example the objectives of the Capability Maturity Model (CMM) explained in a 1987 document that provided an assessment questionnaire. The maturity levels contain the following goals: manage cost, schedule and requirements changes; review design and code; favour process metrics and improvement. I am not an agile expert, but it seems that these objectives share common concerns with the agile practices like Scrum project management, pair programming, focus on unit testing, retrospectives. You can discuss the relative value of pair programming versus code review, but both have a place in the software development toolbox. If you think that the CMM is only created for waterfall life-cyle model with heavy documentation, the 1991 document that presented the key practices stated that the CMM does not imply a particular life-cycle model, a specific set of documents or organisation structure. Measurement is the only major CMM practice not present in agile practices. There are many failures to adopt approaches judiciously in the software development world. If you do not understand the essence of an approach and adopt it without tailoring it to the context, you will face problems. As agile practices spread, they face the same challenges than previous approaches and generate their own “horror stories”. This should not mask the positive aspects of agile approaches… like those provided by the CMM, Information Engineering, RAD or RUP.