The Art of Project Management

15.4. The end of end-game

The closing period of an engineering project is a difficult and mind-numbing process. Jim McCarthy, in Dynamics of Software Development (Microsoft Press, 1995), refers to it as working with Jell-O. Each time you fix a bug, you're effectively touching the big cube of Jell-O one more time, and it takes awhile for it to stop shaking and settle down. The more touches you make, the more variance there is in how it shakes, and the more complex the interaction is among the ripples of those changes. A web site or software product is essentially a huge set of highly interconnected moving parts, and each time you change one, you force all kinds of possible new waves of behavior through it. But unlike Jell-O, with software it's not easy to know when the shaking has stopped. Code is not transparent. It's only through quality assurance processes, and careful manual examination of the builds, that you can understand the effect of that one little change.(11)

This means that the true end of a project is mostly a waiting game. Hours and hours are spent reviewing new bug reports or issues and scrutinizing them to see if they meet the bar for shaking the Jell-O all over again. On larger teams, it's war team that bears this burden. Although the rest of the team should be actively scouting for new issues and using latest builds, everyone can contribute to the waiting game in some way.

But when there's a bug worthy of shaking the Jell-O, everything goes into full gear again. ...