Waterfall and Agile

Does anyone remember when the test of a good software engineer/programmer/developer was if they vowed to never, never use 'goto'? Or insisted that they always clean up their memory allocations? But when you took a look at their code, their techniques for avoiding 'goto's or cleaning up memory made for some high maintenance spaghetti code.

Well, in the software development methodology, Waterfall seems to have befallen a similar fate. And the current favorite for a replacement is Agile.

I was thinking about this as I was upgrading some home software from the version developed in 2005 to the 2008 version. The reason I was thinking about this is that there is some software that businesses large and small only upgrade about that often, because they are core systems. And Waterfall was designed to control the development of vital systems, and Agile expects to roll out new versions of code in months.

I propose that when companies implement Agile, it should be done in conjunction with some good measurements. Determine the percentage of customers who implement the various versions that are released, as well as the number of versions that are released, as well as the overhead that those releases cost. Agile was not introduced to just hurry out as many versions as possible, which I think is sometimes happening.

In the same way that the occasional 'goto' produced more elegant code, some level of control, as came from Waterfall, is still needed for larger core products. In his post PRINCE2 + AGILE = Common sense?, Craig Cockburn makes a good proposal for combining the controls needed for a large project with the flexibility of Agile.