Take the 2-minute tour ×

Software developers occasionally are called upon to write fairly complex bits of software under tight deadlines. Often, it seems like the quickest thing to do is to simply start coding, and solve the problems as they arise. However, this approach can come back to bite you—often costing time or money in the long run!

How do we determine the right amount of up front design work? If your work environment actively discourages you from thinking about things up front, how do you handle that?

How can we manage risk if we eschew up-front thinking (by choice or under duress) and figure out the problems as they arise?

Does the amount of up front design depend entirely on the size or complexity of the task, or is it based on something else?

share|improve this question

closed as not constructive by Yannis Rizos, Thomas Owens, George Marian, Oded, ChrisF Nov 28 '11 at 12:30


Close voters, there are some good points hidden among the chatty wording. Let's try some editing before closing this. –  Karl Bielefeldt Nov 27 '11 at 19:18
Thanks for the edits Karl, I think you've managed to tease out what I was really asking much better than I did :) –  Gian Nov 27 '11 at 19:32
None, hack away \o/. I mean iterate heavily, preferably write unit tests at the same time. –  Raynos Nov 27 '11 at 21:41
add comment

4 Answers

up vote 1 down vote accepted

Sometimes you get the feeling that you have the answer to the problem at hand in your mind. And you know that all you need to is start coding. But that is a really tricky feeling cause the answers that are in your brain is constantly changing.

So there are times that I wished I had documented what i think for a solution. To think about a problem in all aspects is time consuming and a little boring, so i think it is more important to think about one small problem right and write it down somewhere.

share|improve this answer
add comment


When designing keep the above in mind. If you know what needs to happen with/to the data, then you have a design. Design at a high level interfaces within a module, and at a detailed level interfaces that extend outside the module. Do not (unless it's particularly important for a specific reason), design the detail of algorithms.

Leave the implementation detail to implementation. A design is like plan, the only reason to make them is so when things change, you know what impact it will have. The obvious things that change are requirements, however the most common and less acknowledged is the developers knowledge of the requirements and system improve, often making early design decisions obsolete and wrong.

"throwing away" is not a bad thing. It's better to be making progress in the wrong direction than be paralyzed in a design phase. As soon you are learning nothing new about the problem or solution space, it's time to stop designing and start coding.

You don't know everything, and won't until the job is done, accept that, and base your design it.

I hate to think how much time I have spend "designing" stuff, then on day 1 of coding, throwing it away because it was never going to work.

share|improve this answer
add comment

You may want to read this : http://agileotter.blogspot.com/2011/10/if-we-had-done-right-thing-to-begin.html

In short, you didn't know when you start every problem you will encounter, so you have to learn refactoring and don't expect to get the right design think everything up-front. Software doesn't work that way.

You know you have done enough up-front when you solved the problems you KNOW you will face. Not the all the problems you will face and not the problems you think you will face. The difference is capital.

share|improve this answer
So you think the best strategy (and the one advocated by the link, as far as I can tell?) is to really eschew up-front thought, and just plan to refactor as problems arise instead? –  Gian Nov 27 '11 at 19:44
@Gian > No, it doesn't mean that you shouldn't think at all up-front. But don't try to anticipate, and accept that you can't get the right solution before starting. –  deadalnix Nov 27 '11 at 21:04
"Maybe finding the right thing is a combination of up-front thinking and ongoing discovery; maybe it always has been." -- from the quoted article, which is from me. Tim "Agile Otter" Ottinger –  tottinge Dec 1 '11 at 2:28
add comment

An essential attribute of a good software is that it gets the job done. This means that it can do the required functions in an acceptable way to the user(s). As a result, we could say that, if you know:

1 - What needs to be done (system objectives, constraints, functions, use cases, business rules, etc.)

2 - Which user can do what (security, authorization, etc.)?

3 - When each function can be performed (schedules, workflows, etc.)?

4 - How to implement the above in an acceptable way (architecture, friendly GUI, data modeling, framework adoption, etc.)?

5 - Who will do the work?

and if your user is happy about your prototyping, presentations, understanding of buiness, then chances are you are good to go and can produce an first cut plan for the code development part.

I recommend that you separate analysis, design and coding.

I also recommend that you have a stable data model and good detail about the majority of the system functions. It is not very harmful if you discover that you are missing a function (assuming that it is local to your system domain and won't require external APIs), and it is OK if you are missing some business rules when you start but it hearts more to discover that your data model is wrong or missing significant pieces because this usually fires back on the GUI work not only on the data layer.

Depending on the methodology you use, you could find estimates on how much effort you dedicate for requirements and design. I am very tempted to say that front work would eventually consume at least 25% of the total project work but any estimate I will come up with will be wrong because it really depends on too many factors.

Agile and XP methods have things quite different than what I suggest. In fact even on the database side, there is Agile Modeling approaches that you may want to consider. The advice above are not based on those techniques.

share|improve this answer
add comment
