Wednesday, January 18, 2012

Develop, Test, Release, ...

No amount of slick propaganda can rearrange the basic software development life cycle:

Develop, Test, Release, Repeat
No one can put Release before Develop, not unless they have a time machine. It is possible to put Release before Test but that is usually so unsuccessful that an impartial observer might say the Release never happened.

If the same staff are involved in both Develop and Test (as they often are, and perhaps should be) then a big problem can arise when the cycle reaches Repeat:

It's hard to go back to development when you've been testing for release.
During final testing the code is usually frozen and everyone is risk-averse. The only changes allowed are those required to fix problems, and not all problems are fixed... no one wants to make any changes that might break something else.

After the Big Release Day, it's time to Repeat which means go back to Development. For management, that's easy: it's all just one long schedule to them, just one day later, and there's probably been some slippage which means everyone's already late for the next Release.

For developers, it's not so easy... especially if they just came off the death march called Test. They're still risk-averse, and Development requires risks to be embraced: Concentrate on the enhancements without obsessing about the effect they might have on the rest of the program. They're also tired, and Development requires enthusiasm.

What the developers need, and often do not get, is an extra step to decompress and rejuvenate:

Develop, Test, Release, Relax, Repeat
A word to the wise for management: If developers don't get time to Relax, they'll take it anyway... perhaps not consciously, but through bad morale, lost productivity and extra sick time. And it might cost more in the long run.

Or... you could try rewards, see if that works...


Anonymous said...

The most effective way to mitigate risk-inducing development with a risk-averse developer (that I have found) is a good CVS with branching and merging. Label the code in your CVS and release. Then create a branch and start developing. Who cares if you break something? You can always just roll back to your labeled release.

Breck Carter said...

@Anonymous: I won't say you have missed the point, Scott Adams did a much better job of that in 1994: