Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question

migrated from Dec 10 '12 at 6:37

This question came from our site for professional and enthusiast programmers.

[Citation needed] – Dour High Arch Dec 5 '12 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 '12 at 10:38
What makes you think this is a standard rule of thumb? Can you site a reference? – Bryan Oakley Dec 10 '12 at 12:13
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.? – zooropa Dec 11 '12 at 3:54
Who cares?..... – Jim G. Dec 11 '12 at 4:32

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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