Maybe its just because I'm following Simon Brown on twitter, but I saw a phrase like "just the right amount up-front design" often enough to make me think.

Am I doing the right amount of up-front design?

I never before thought about this question in my software projects. But I also hardly ever had the feeling of "damn we did to much or to little of it back then". How can this be possible? The reason might be that in some sense my approach to hitting the sweet spot for the amount of design is extremely easy:

Design as much as possible, as early as possible! But not more or earlier!

So some people might imagine me now sitting for weeks in a row working with UML tools and hammering out diagrams and design documents. Nothing could be farther from the truth. The key is in the interpretation of  when design is possible. For me design is all about solving a problem. So in order to do some designing one needs a problem. If you have found a problem do as much design for it as possible. 'much' doesn't get measured in hours or number of pages or diagrams. 'much' gets measured in the extend to which the problem gets solved. If you can design a solution that makes a problem go away. Great! If you only find one that makes it a tiny problem: It will have to do until you find a better solution.

But now we are stuck with trying to find a better solution for a not completely solved problem, right? Wrong! In reality we have lots of problems in a project, so we pick the worst one whip up the solution, until the next problem is bigger then the first.

So if you are spending time with a problem that isn't the most pressing one, you are doing to much up-front design. But everybody would immediately stop doing it once he realizes it, right? If on the other hand you are knowingly ignoring your biggest problem you are doing to little up-front design. But the more common name for this is sabotage.

Of course it does happen that what you thought is a great solution turns out as a bad idea, or that you just can't find a solution for a especially bad problem, or a problem jumps at you from behind. Congratulations you found the border of your skills. Its an opportunity to learn an to train you problem identification or solving skills. It is not the time to decide, I should do more of it (or less) next time.

It really is a simple process. Yet software design is considered difficult. So where is the difficult part?

There are actually three difficult parts:

• Seeing the problems as early as possible, so you can solve them while they are small
• Finding good solutions fast.
• Having a great team that understands that every software developer is a software designer