How to determine the right amount of up front design? [closed]

Question

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?

Answer 1

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.

Answer 2

"Show me your [code] and conceal your [data structures], and I shall continue to be mystified. Show me your [data structures], and I won't usually need your [code]; it'll be obvious." Fred Brooks

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.

Answer 3

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.

Answer 4

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.