Software Debugged

The agile approach to software development is all the rage these days. This must be a good thing because when handled well, the flexibility agile methods afford makes for much greater cost effectiveness, for example:

• Changes in the business requirements can be handled right up to the very late stages of development
• Iterative development, and the production of the product so far at the end of each iteration, aid the picking up of misunderstandings and/or need for changes to the specification

However, I fear that – like many things in software development – the agile approach is frequently misunderstood. Just as worrying is the anecdotal evidence that it is being abused, in that the meaning of “agile” is being twisted in order to justify chaotic development.

Here are some examples, the first two being examples of the former, and the third being an example of the latter:

Example 1

In the article More Than Coding Mistakes At Fault In Bad Software, the author Alexander Wolfe says:

"That waterfall model was replaced by a process (and I use that word loosely) where the modus operandi was to cram in as many features as possible before the shipping cut-off date, and then fix the problems in beta. (Sure, I know time pressures mean waterfall wasn’t rigidly adhered to, and also that it had deficiencies, leading to the 1980s flowering of alternatives like agile-development and object-oriented programming. But at least we had a model.)"

The final sentence of the above quote - "But at least we had a model" - suggests to me that this author does not view agile development as exemplifying any model at all. I guess there is much scope here for a (semantic) debate over what model means in this context. To me it is clear that, while agile processes vary, there is a core model that they all adhere to - albiet quite different from the waterfall model. Sorry, no further explanation here, but I’m aiming to pick this up in a future article. In passing, I’m rather baffled by this author’s characterisation of object-oriented programming as an alternative to the waterfall model. Object-oriented programming is orthogonal to the waterfall model. Actually it is orthogonal to the development process model/mindset per-se.

Example 2

A few years ago I was working in a development group where the manager had been reading about extreme programming (XP). He proceeded to dismiss it as "licensed hacking". This was based on the XP doctrine of anyone being able to refactor code as they saw fit. He had great difficulty grasping the fact that XP practitioners take for granted, as part of their development culture, practices that he could not even envisage using. For example, two such practices are test driven development and the ongoing peer review of code (via pair programming). Unfortunately, this manager was not open to modifying his opinion – he knew what he was talking about!

Example 3

I have been quite lucky with the development groups I have worked in, in that I have not personally worked in one where the agile approach is being twisted to justify chaos. However, the following did come up in an interview:

The manager of the development group proudly told me that the (C++) development group had gone agile and were developing in two week iterations. However, I quickly discovered they were not doing any test driven development – or even any unit testing for that matter. Further, they frequently had to work long hours, or even overnight towards the end of iterations, in order to get all the functionality expected from that iteration into the product. It seemed that pushing functionality forward into a later iteration was not acceptable.

Actually the above was in a telephone interview and I declined the offer of moving on to a face-to-face interview! Also that’s the only example from my own personal experience, I have come across several similar ones in conversations with other developers.

Finally

Unfortunately, examples of the abuse of agile development such as that last example only serve to strengthen the prejudices borne out by the first two examples. Right now, I’m afraid I don’t have any suggestions as to what the genuine agile development community can do to - over and above what is already being done - to change this.