Brooke's Law doesn't include scaling effects. They're geometric. [There is another effect I can't yet name that kicks in for very large projects so they can never complete. This isn't just an asympote, but a maximum - total output reduces the bigger you make the project team without relaxing the time constraint.]
Here's the heuristic scaling law:
To double output, triple the resources.
[No evidence or research to support this.]
If you have 10 units of work to do and your staff of 6 can do it in 3 months, to produce 20 units of work in 3 months, you need 3 teams of 6 [modulo their effectiveness and project initiation time]. For 40 units, 9 teams, 80 units - 27 teams etc.
Alternatively, what the team can do in 24 months, might be possible in 3 months with 27 times more resource - or around 8 times the total cost, if it ever completes. [I don't have any ideas on the increase in unreliability of the estimates or the 'Project Risk' increase.]
Sometimes "Fast Tracking" may be necessary... But hugely expensive - and where are you going to find around 25 times as many people???
The Standish Group have been performing Primary Research (surverys) of I.T. in the USA since 1994. They've accumulated a large amount of data and 50,000 project case studies.
Their "Recipe for Success" (for I.T. projects) is simple - six people for six months.
It seems to confirm this hypothesis.
"Cheap, Fast, Good - pick any two".
From an article in "Software Magazine", Here's the list of Standish's Top Ten:
Recipe for Success: CHAOS Ten
Confidence Level Success Factors
Executive support 18
User involvement 16
Experienced project manager 14
Clear business objectives 12
Minimized scope 10
Standard software infrastructure 8
Firm basic requirements 6
Formal methodology 6
Reliable estimates 5
Other criteria 5
Thursday, March 1, 2007
Mythical Man Month II
The Mythical Man Month Revisited
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.