I once heard that if you spend 90% of your time developing the design of your program the coding part will only take a trivial 10% of the time. I have found a lot more success in spending about 30% of my time designing the architecture than when I used to spend 0% in design. As a result my programs seem to avoid unnecessary coupling and are now more flexible to change before any re-factoring takes place.

I usually finish the design phase once I have a clear idea of what all the objects should be named (I am really picky about naming objects) and what single responsibility each will have. Once I feel confident in my design and feel ready to start constructing the software, would there be any benefit to taking more time to keep re-thinking the design? To me it might seems like it might be overkill.

What's an effective design to code development time ratio and should the design time be greater than the code development time?

  • 14
    This reminds me of one of my favorite quotes: "The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time." - Tom Cargill
    – David
    Commented May 22, 2013 at 14:18
  • 2
    Taken to an extreme, it could be considered Big Design Up Front. Commented May 22, 2013 at 20:17
  • 1
    This is a nice extreme to read: fastcompany.com/28121/they-write-right-stuff Could be good could be bad, it depends on the project. Commented May 22, 2013 at 20:21
  • 1
    coding is design
    – jk.
    Commented May 23, 2013 at 10:42
  • 1
    @KoreyHinton: BDUF is a concept from Agile Software Development in so far that it is presented as an opposite of what Agile stands for. Commented May 23, 2013 at 11:04

4 Answers 4


When making traditional estimations, my experience is that the effort distribution is roughly 30% design, 40% implementation, 30% test and usually the design is considered complete when you have identified the relevant classes, their responsibilities and optionally the major methods.

One of the risks that you run when doing a very complete and comprehensive design is that you can run Analysis Paralysis, which means that you never get anything done, because you keep 'improving' your design without a clear benefit for the current situation.

So, there definitely is an optimum in the amount of design to do, and that optimum lies around the point where you feel comfortable that your design addresses the relevant requirements and is detailed enough to act as a guide during the implementation.

  • 2
    Excellent answer. There should be just enough design to get you started. Endlessly analysing an abstract design is self-defeating. It is a means to an end - not the end itself.
    – Robbie Dee
    Commented May 23, 2013 at 10:49
  • Thanks for your answer! It's good to know the consequences of doing too much design and I'm glad I have a name for it now. Also, your estimations were very helpful as well. Commented May 23, 2013 at 14:06

First, it depends on the kind of project. Is it similar to something you have already done, repeatedly? Then your coding part can be extremely short. On the other hand, if it is completely new, with a lot of new functionality, then you probably need to code a lot of functionality. (Well, or use an existing library. Which needs to be tested. Is testing of a new library considered a part of development?)

Second, what exactly is your definition of "design" and "development"? For example, one person draws classes in UML, and at the end compiles them to code. Another person creates classes in IDE and refactors them, but does not write method bodies yet. The former one's work would probably be classified as "design" and the latter one's as "development", yet they are doing the same thing, just using different tools. (A more philosophical person could perhaps argue that all coding is design.)

Third, it probably depends on the programming language, methodology used, etc. Shortly -- if you made a mistake in the design phase, would it be easy or difficult to notice? Because if you don't notice it in the design phase, you will have to find it and fix it during the time officially spent developing.

  • 1
    Good point about design and development confusion Commented May 23, 2013 at 14:09

I don't think that you have to use some "90%" as golden rule, just use what is best for YOU. I would think of it as guide line to spend more time on thinking how to do it, instead of trying by permutation.

Just say loud NO to "golden rules", use them as indicators yes, enforce them never.

  • Yep, as soon as someone says "always do this..." or "never do that...", I switch off - because it indicates that they've stopped actually thinking about the problem in hand.
    – Robbie Dee
    Commented May 23, 2013 at 10:52
  • Thanks for your advise. My programming has gotten better because I have given more time to design/planning but that doesn't mean that I will find more success if I keep giving more time to design. At some point too much design becomes Analysis Paralysis as Bart said in his answer. Commented May 23, 2013 at 14:18

I tend to plan more in projects, which are similar to those I already did. Because I know what worked last time and what didn't, so I can get more into details in the planning about the architecture.

When I do something new, I have a vague idea about what I have to do. But start coding right away and throw the bad ideas out early has proven to be a better idea than planning a bunch of stuff AND implementing it later, just to see that the plans were flawed it the first place.

So the more I know about the software I'm going to implement, the more I dedicate to planning.

  • You make a very interesting point. I've ran into API restrictions before in implementation that caused design changes during the development phase. Commented May 23, 2013 at 14:12

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