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

Is it bad that I often find myself spending more time on program structure than actually writing code inside methods? Is this common?

I feel I spend more time laying the foundation than actually building the house (metaphorically). While I understand that without a good foundation the house will cave in, but does it legitimately need to take half of the project to finalize code structure?

I understand design patterns, and I know where to go if I need help on choosing one, but often I find myself doubting my own choices.

share|improve this question
up vote 14 down vote accepted

No, it's not common, but yes, it should be common.

Having the correct organization of a large project is way more important than any single method in itself. If your project is organized well, it is comparatively easy to understand part of it. If a small change is necessary in one isolated part, it becomes easy to find the class or method concerned, to understand what it does, and to change it from one obvious behaviour to a different obvious behavior.

Having lots of self-contained methods and modules that seem almost to small to make sense is a good thing. Any individual method should be near-trivial to write and read. Many practitioners make the mistake of thinking "Oh, this is trivial to understand, it can't hurt to add a bit more functionality - it will still be pretty clear." Resist that urge with all your power of will; instead, exert this effort on a well-thought-out macro-structure, so that it remains trivial to find, read and change each part when necessary.

(The reasons that this isn't done more often are complex and probably intractable. Writing something that works well at first and slowly becomes unfit for modification seems to give quick return on investment, and many managers are unable to comprehend that a system which you can almost work with may be very expensive to transform into one that you can actually work with in the future. But that's no excuse for not doing the right thing in the first place when experience has taught you to do so.)

share|improve this answer
+1, especially for "Having lots of self-contained methods and modules that seem almost to small to make sense is a good thing.". Consider that if each method / function contains at most two statements (each of which can possibly be a method / function call), you can still create an arbitrarily complex application very fast (exponential blow up). – Giorgio Apr 21 '13 at 12:06
How is following a never-ending trail of indirection ("treasure hunt"), that will inevitably result from this insanity, easy to understand? That's just going from one extremity to another, and is probably far worse than the extremity you started with. Each method contains at most 2 statements - are you serious? – Esailija Apr 22 '13 at 14:41
You are not supposed to follow it. If a method is called "changeUserName(string)", do you need to follow inside to see what it does? That is the point of short and well defined methods. – Davor Ždralo Jul 4 '13 at 14:57
Related quote from the Cathedral and the Bazaar: 9. Smart data structures and dumb code works a lot better than the other way around. – o11c May 27 '14 at 20:15

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.