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.

What ever happened to the rollback plan?

Over Christmas, I found myself saying "That's why I got into the Quality software business!" When you ship packages through USPS or UPS or FedEx, you get a tracking number that purports to tell you where your package is, every step of the way. One of them, consistently said "we will be receiving it from its origin on xxxx". Even after it was delivered! Now this worked great last year.

I happen to know that it is pretty normal to upgrade software once a year. Here's the thing - last year, the software worked great. What changed? I'm guessing a new version happened. And here is where it goes wrong.

When did we stop having a good rollback plan? When you have software that works, and works well, you should be very careful in your upgrade plans. And always, always be willing to rollback to the previous version that worked so well. And anyone writing new software needs to be ready to have that software rolled back. But too often, upgrades happen, and happen poorly. It could be personal, as when you upgrade your personal software, it changes the storage of the underlying data, and when there is a problem, you can't figure out how to go back. Explanations and documentation of what is being changed may, on the producers side be poorly written, or, on the installer's side, be poorly read! One of these things seems to have happened with holiday shipping this year.

So, whatever happened to the rollback plan?