Summary
A reader questioned my project-estimation technique in "Thinking in C++, Volume 1."
Advertisement
Hi Bruce and thanks for your great work with the Thinking in C++ books!
I just started reading the second edition of your volume one and I saw that chapter 1, note 13, where youre talking about estimating the necessary time by doubling the feeling time etc. Dont you think that taking a higher multiplier will just raise the effect of the Parkinson Law? [Work expands so as to fill the time available for its completion, http://www.heretical.com/miscella/parkinsl.html], so that with a higher multiplier, you would just report the effort till the end of the project (and higher the resources cost ) Maybe the best way would be to better plan the project iterations / milestones so that the effort is more balanced overall.
What do you think?
Parkinson's Law is flawed in so many ways -- see for example the book Peopleware, where it shows that the highest productivity comes when there is no schedule at all. Peopleware pokes holes in all kinds of "common knowledge."
And note the cynicism implicit in Parkinson's Law. Programmers and people in general want to be productive, but PL has an assumption that they want to fool around. Also see Gerald Weinberg's books; especially "Becoming a Technical Leader." And any number of time management books, such as David Allen's "Ready for Anything."
Your gut-level estimate must be honest, however. And it must have been early when I wrote that, because I usually estimate 4x the gut-level estimate.
Of course it's more ideal to measure each iteration a la XP and see how fast you are going, rather than trying to hit a particular mark. But if people want a top-level guess as to how long a project is really going to take, without any XP-style feedback, then the 4x metric is pretty good, I think. Of course it's always a guess when you don't have any real data, but if people insist on a guess then that's one that produces enough time.
Also see Peopleware about the impact and detriment of constant overtime, if you are leaning towards Parkinson's Law, which has certainly caused enormous damage to projects by assuming that you have to give an unrealistically short schedule or people will fool around.
> Parkinson's Law is flawed in so many ways -- see for > example the book Peopleware, where it shows that the > highest productivity comes when there is no schedule at > all.
Parkinson's law specifically doesn't apply in the case there is no schedule (there is no "allocated/available" time to fill).
> Also see Gerald Weinberg's books; especially "Becoming a > Technical Leader."
In addition to that one, I'd also like to recommend "The Psychology of Computer Programming".
The Mythical Man-Month by Fred Brooks is also a relevant classic.
Another reason to believe Parkinson's Law doesn't apply is that it describes a defect in how corporations operate, not a universal law of nature. If the corporation doesn't use simple, single-criteria success factors to decide on promotion, people don't rise to a level where they are incompetent. It's when corporations use single criteria, like sales figures, to decide who gets a promotion, that they promote incompetent managers.
That said, there is nothing sacred about multiplying by four, and I generally don't favor that kind of scheduling. I prefer to determine from real metrics why the estimates were off in prior projects and correct the problem.
I found one useful one I rather like: make a best-case estimate, a worst-case estimate, and a best-guess estimate. then calculate the final estimate using the formula:
I love rule of thumb estimation sayings. My personal favorite was "Double the gut estimate, convert to the next larger units, and add 1 of the original units" So 1 day becomes 1 week plus a day. One hour becomes 2 (work) days plus an hour, etc. I found this to be useful because you immediately start thinking "how the heck could it take so long?" And your mind will immediately fill in with test writing, debugging time, spec gathering, documentation writing and all the other things a typical developer skips over with a first estimate.
IMHO the coefficient by which you multiply your gut feeling has to be slightly different for whoever is guessing. I found my current value (about 2.5) by grossly underestimating my last project (then again, since this is only my third commercial project of very limited scope, I can't claim any competence here), and found it a good idea to partition the project into subtasks and milestones and rather try to estimate those. At least then I notice quickly once I'm out of schedule. This time it worked :-) though if this'll continue on for the next project remains to be seen.
Previous Topic
