Know Your Enemy – How To Make Budget

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/3 planning
1/6 coding
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.

Talk about us!

  • soitgoes3

    I’ve found that the concept of divisible tasks one of the easiest concepts, however it’s one of the most difficult to orchestrate and practice.