Everyone thinks they understand bug economics. Walter Foyle looks again.
A popular work concerning project management is Fred Brooks' The Mythical Man-Month: Essays on Software Engineering . While it has many interesting insights into the economics and process of creating software, it is most often remembered for two specific observations, and yet I believe both have been profoundly misunderstood. This is because people are looking at it from a project management point of view, and are missing the economic aspect where project budgets are far more important.
The most famous lesson people remember is that adding people to a late project makes it later. While this is true if you myopically focus solely on your current project, people tend to assume that this is necessarily a bad thing. In fact, a more rounded project manager realises that by increasing your developer count now, you will have a bigger project and hence budget, so putting yourself in a much stronger position to get a more prestigious project in the future. By a process of induction, it can be shown that by repeatedly adding more developers, you can make the project arbitrarily late until you reach the optimum size for you to get the next job.
The other main observation from Brooks is that the cost of fixing a bug increases dramatically the later it is found (see Figure 1). Many have jumped to the simplistic conclusion that this means we should strive to detect and fix the bugs as early as possible. And yet most don't realise the more sophisticated truth that this in turn implies that by introducing the bugs sooner, we have a better chance of detecting and fixing them when they're cheapest. In fact we can improve these chances further by moving all the coding to before the design phase, which normally delays bug detection and so can be thought of as a negative value activity. In addition, delaying the release as far as possible into the future further improves the opportunities for bug detection. Finally, moving testing to after the release frees valuable developer time and has the bonus of reducing the observed bug count.
This all assumes we are blessed with a team productively working on such bugs. Unfortunately, there will often be people who slow down projects rather than advance them. By assigning these people to the unproductive yet politically essential Design Role (or the more trendy role of On Site Customer), we can multiply a negative outcome (too much design delaying implementation and thus delaying the bugs), with a negative ability to do such a thing and thus produce a positive budget item. Just in case anyone objects, the canny Project Manager can use the appropriate spreadsheet magic and to package up these Customer Design Obligations and assign to multiple ongoing projects, so spreading the project risk and making sure that none of their project economies can possibly fail. Ideally these should be stored in Write Only Memory[ WOM ] along with other Documentation Artifacts to protect the project stability in the face of awkward questions.
>
|
| Figure 1 |
Of course, sometimes the customer will insist on a meeting to ask when the delivery will actually be. Unlike normal meetings, which are designed to reduce risk by avoiding doing anything that might cause troublesome progress, these meetings require a swift and firm response. I can recommend sending a memo round immediately to reassure all interested parties that everything is as it ought to be. Ideally this should merely sound reassuring without actually promising anything, as in this masterful example:
The meeting was productive and actions have been agreed by both parties, commencing with early technical meetings this week, which if carried through, should lead to the resolution of the issues. Provided there is the expected progress during the coming weeks, both parties are hopeful that it will be possible to indicate by the middle of April the target date for trialling and then operating... [ CEN ]
By applying such techniques, we can ensure that our projects are large, long, and avoid suffering at the hands of troublesome users.
References
[CEN] http://www.cambridge-news.co.uk/Huntingdon-St-Ives-St-Neots/Date-for-opening-expected-after-busway-progress.htm
