April 19, 2006

...Learn TDD with Codemanship

Beware! Stabilizers

Is this a new trend? I've been coming across various companies who purport to do bespoke software development, and they each have a rather familar - yet slightly odd-looking - development methodology lifecycle.

They have phases that look somewhat like the Unified Process, but one can't help wondering how many of the UP best practices they're actually using. I wonder if they're doing actual, real, bone fide, honest-to-non-existent-supreme-being iterations, for example. The biggest indicator that they might not be is the addition of what they call a "stabilization phase".

I've had the dubious pleasure of working with a company who used such a phase, and I can assure you that - in their case - it's exactly what you think it is: rework & bug fixing (and lots of it!)

The stabilization phase occurs just after the software is first released to the customer for acceptance testing, and this happens towards the end of the release cycle. Actually, once the customer's feedback is in, it usually turns out to be far from the end of the release cycle once they realise that a big chunk of the system will have to be reworked before:

a. The customer will use it, and (more importantly)
b. They'll even consider paying for it

If they'd been delivering in small increments to the customer all the way along, then there should be significantly less need for such a contigency.

What's slightly worrying is that the customer in the example I saw was actually sold on the idea of this phase. The developers made a big play of it in their pitch. The client accepted that there would always be a need for rework, so it seemed quite logical to them to build in what is effectively a rework phase towards the end of the project.

If I were the customer, that would make me feel very uncomfortable. Waiting until we're near the planned release date to find out what my $millions were actually spent on would have me waking up in cold sweats.

But rework was always part of the equation, wasn't it? Why introduce a special phase for it? It's a contingency built into the plan, and very probably into the deal. They're planning to do a big chunk of rework, and they're planning to bill you for it!

These "stabilizers" are relying on clients who aren't familiar with software development best practices to sell rework - effectively turning a major failing into a competitive advantage.

But don't so-called "agile" teams do a kind of rework, too? Well, yes, they do. A good Agile team will probably spend more time and effort responding to feedback than they would trying to get the software right in the first place. So surely they'd take just as long and cost just as much as the stabilizers?

Well, no. Imagine two ships, both going from New York to Sydney. Ship A sets off in roughly the right direction, and the captain corrects his course - based on observations of the positions of the stars - every night throughout the journey. Ship B sets off in precisely the right direction, but the captain waits until they're almost due to arrive at Sydney before taking the wheel again.

A manager - who I shan't name - drew this little proof on the whiteboard to back up his claim that one big rework at the end really is equivalent to a whole bunch of little reworks throughout:

Can you spot the deliberate mistake? Yep. If the captain of ship B only steers on day 29, then his route should look more like this:

It's basic physics and geometry, really. After 29 days, the time that ship A spent getting back on course, ship B spent going further off course. Ship B spent nearly double the time ship A spent going off course, and that is what I refer to in Agile Maintenance as double the technical debt. And the technical debt has to be repaid at some point - often long after the original developers have moved on.

So the waterfall approach of saving the bulk of the rework for last makes very little commercial sense.

"Ah", replied my manager friend, "but the captain of ship B knew the precise direction before he set off, so he wouldn't have gone in the wrong direction in the first place..."

To which I replied "remind me not to go sailing with you"...

Anyhoo, you have been warned:

Stabilization phase = waterfall = technical debt = much longer and more expensive journey
Posted 1 week, 3 days ago on April 19, 2006