Summary
A reader questioned my project-estimation technique in "Thinking in C++, Volume 1."

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 you’re talking about estimating the necessary time by doubling the “feeling” time etc. Don’t 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.

Talk Back!

Have an opinion? Readers have already posted 7 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Bruce Eckel adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Bruce Eckel (www.BruceEckel.com) provides development assistance in Python with user interfaces in Flex. He is the author of Thinking in Java (Prentice-Hall, 1998, 2nd Edition, 2000, 3rd Edition, 2003, 4th Edition, 2005), the Hands-On Java Seminar CD ROM (available on the Web site), Thinking in C++ (PH 1995; 2nd edition 2000, Volume 2 with Chuck Allison, 2003), C++ Inside & Out (Osborne/McGraw-Hill 1993), among others. He's given hundreds of presentations throughout the world, published over 150 articles in numerous magazines, was a founding member of the ANSI/ISO C++ committee and speaks regularly at conferences.