Should the design take longer than code development? [duplicate]

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.