Fred Brookes wrote a definitive book, "The Mythical Man Month" on the management of large projects. He reported the development of the Operating System for the (then) revolutionary "IBM/360" around 1960.
His main conclusion is usually stated as: "Adding more programmers to a late project only makes it later."
Take together the last set of posts on programming/I.T. productivity factors:
Teams, Staff 'Morale/Attitude', Star Performers, Nett Negative Producers and Ineffective Management.
All the factors multiply together - the range of productivity, even for the same staff, is tremendous.
How can sensible "Man Month" estimates be made in these conditions?
Brooke's Law can be explained by a computer analogy:
It's a 'cache coherency' problem. The memory of the existing staff is being copied to the new staff - both groups cannot produce anything until the transfer is complete.
Projects and Admin/Operations tasks can't be forecast using a "mean average person" - individual forecasts have to be made for the productivity of the specific person, team, project, environment... And if you are "Going Boldly Forth where No Programmer has been before" - isn't that the definition of "research"?? It's a creative endeavour - you are done when you're done, not before. Applying pressure, especially in the form of deadlines, is counter productive. Only the bravest of staff will 'push-back' and refuse to release incomplete, incorrect and buggy code or services. And once a 'milestone', like any Victory in war, is declared complete, there is no going back. The body of work, no matter how poor, can only be tinkered with, never fixed.
Or restated: By applying arbitrary deadlines, you guarantee faulty code. Then you are stuck with the mess as the foundation for the rest of your work. You will slowly drown in the morass of your own mistakes - and all easily preventable.
The real Myth, is that there is an average person who's output can be projected.
The best person to forecast completion of a unit of work is: the one who's going to do it!
And the 'horizon' is only clear for about 2 weeks ahead. So detailed work plans can only be constructed for the immediate future. Yes, there will be a design, but it will evolve and it will be a set of road signs.
The old rubric applies: Double your best estimate, then double it again.
And don't take on tasks you don't know how to do... You'll only create a huge mess, and everyone, including you, will be very sorry.
Thursday, March 1, 2007
The Mythical Man Month Revisited
Posted by steve jenkin at 1:03 AM
Labels: man-month, myths, software productivity
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment