A Programmer’s Haiku
For on-time launches
We admire to dispel
A programmer’s optimism
— Marshall Malone
Experience teaches a developer that the qualities that make great programmers can also break them.
Programmers are artists. Programming is a synthetic art. Programmers create something from nothing. Therefore, it is not a stretch to say that a programmer, by nature, is an optimist.
The difficulty, however, is that a programmer’s belief in himself, or a project’s outcome, does not always allow him to factor sound logic in his construction of a timeline. When this happens, his optimism has failed him and the client. Most programmers will admit that they consistently underestimate how long it will take them to accomplish a task.
I’m inspired by the book; The Mythical Man-Month, by Frederick Brooks, Jr.; a well-known IBM developer. At the book’s core, he dispels the notion that adding man-hours to a project will speed the pace of that project. In fact, he affirms “adding manpower to a late project makes it later.” In describing this assertion, he uses the analogy that 9 women cannot work together to produce a baby in one month.
The Man-Month, in a timeline, suggests that X number of men can accomplish Y many tasks in Z many months and that the men and months are interchangeable. (more men = fewer months, more months = fewer men, etc…) As eager as programmers and patrons are to see a project to conclusion, many employ this myth into their logic. This brings a slow and painful death to their client’s satisfaction.
Brooks says, “Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them.” In other words; when tasks require heavy communication, the project doesn’t speed up with more effort. In fact, adding man-hours can slow a project down.
I remember a client’s story; how 2/3 of their team was replaced with “better developers” in the middle of the project. Though the developer believed and even insisted they would be on time, his reasoning was based on a false and optimistic notion; the mythical man-month. As the client feared, they launched almost 6-months later than intended, and by the end of the 6th month, everyone was seeing blood.
At the root of this is the understanding that programmers don’t just slip into a project. They require training by those people who are experienced in the project. For example; adding 2 men will require at least 3 man-months to get them up to speed; time, which is most likely, not budgeted in the original estimate. This also means the tasks are redistributed 5-ways so that by the end of the 3rd month, 7 more months of effort remain. With 5-trained people standing; only 1-month remains in the budget and the product is now late, as if no one had been added.
To hope to get done in 4-months, considering only training time and not repartitioning and extra systems test, would require adding 4 men, not 2, at the end of the 2nd month. Now, one has at least a 7-man team, not a 3-man [team]…”
And the client suffers as their expectations far exceed the reality. There are two prices that every client pays when a project falls behind.
- The financial and psychological costs to both developer and patron because of added man-hours.
- The impact of late software on a business, which depends on the project to support the business efforts.
As costly as this is, it is a failure by most developers to deploy sound planning principles. Instead of calculating myths, the average project should look like this, according to Brooks:
1/4 component test and early system test
1/4 system test, all components in hand
- The number of months of a project depends on its sequential restraints.
- The maximum number of men depends on the independent number of subtasks.
From these two quantities one can derive schedules using fewer men and more months. One cannot get a workable schedule using more men and fewer months.
Until estimating is on a sounder basis, individual managers will need to stiffen their backbones and defend their estimates with the assurance that their poor hunches are better than wish-derived estimates.