I'm looking for a reference to the following. I commonly hear that one-third of a projects time will be spent in design, one-third in implementation, and one-third in testing. The three phases of development seems to be derived from the waterfall model. But, where did the time division originate (1/3, 1/3, 1/3)? Is there a paper or book that this is from?

  • 6
    [Citation needed]
    – Dour High Arch
    Dec 5, 2012 at 19:08
  • This was discussed on MSO prior to being migrated here. The way I read the question it's about finding the source of an oft quoted rule of thumb (I've heard the "1/3 rule" quite a few times myself), and not about discussing its merits - we have a ton of questions about estimation in general were answers discussing the merits of various estimation techniques would be more appropriate.
    – yannis
    Dec 10, 2012 at 10:38
  • What makes you think this is a standard rule of thumb? Can you site a reference? Dec 10, 2012 at 12:13
  • @BryanOakley It probably isn't a standard rule of thumb, but I've heard it (or slight variations of) constantly since my early days in the field, a little bit over a decade ago. I'm certain I also read it somewhere online, but I can't remember where (and it probably was some blog or something like that).
    – yannis
    Dec 10, 2012 at 12:37
  • 1
    Bryan Oakley, you are asking my question. I am asking for a reference when I ask, "Is there a paper or a book that this is from?" What person originated this rule of thumb? Brooks (Mythical Man Month), Yourdon, etc.?
    – Paul Kelly
    Dec 11, 2012 at 3:54

1 Answer 1


The rule of thumb you're describing sounds extremely similar to Brooks' rule of thumb, as presented in the Mythical Man-Month:

For some years I have been successfully using the following rule of thumb for scheduling a software task:

1/3 planning
1/6 coding
1/4 component test and early system test
1/4 system test, all components in hand.

This differs from conventional scheduling in several important ways:

  1. The fraction devoted to planning is larger than normal. Even so, it is barely enough to produce a detailed and solid specification, and not enough to include research or exploration of totally new techniques.
  2. The half of the schedule devoted to debugging of completed code is much larger than normal.
  3. The part that is easy to estimate, i.e., coding, is given only one-sixth of the schedule.

I don't know where exactly your rule of thumb comes from, but it certainly looks like a derivative of Brooks' rule of thumb.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.