How would you balance between designing and (actually) implementing you application

Question

My question is not programming language specific, but its more generic question to see the way of people thinking.

Usually in Large development houses there are specific roles for each job, such as Programmers and architects. so architects point of view is to have a perfect architect and solution design, on the other hand programmers are dealing with actually implementing application features and UI stuff. Therefore if you let the architect for example working on the application with out programmers you will get an application perfect frominside (design patterns, classes, DB tables) but nothing from outside, also it applies vice versa. Programmers always focus on the output without giving too much concern for design principles (for instance SOLID principles).

Now i am working on a small firm with team composed of 8-10 people max, so you need to take care of your application design as well as implementing the features. So my question simply is

• when do you need to stop designing and implement you solution?
• or should it be incremental work?
• what if you reached a point where you screwed up just because you didn't design well from the beginning ?

I hope we can have a different ways of thinking so we can come-up with multiple acceptable solutions

Answer 1

Thinking a problem/design through thoroughly will improve the final code. But unless you spend months on the design when you write code you will discover flaws in the design, new features you didn't think of, or interactions you didn't anticipate. And on most software projects the goal-posts will move (the customer will want something slightly different, or you'll have a great idea part way through, etc).

Waterfall appraches tend to go for the whole design being completed up front before you have any idea about how the code will pan out - this is inflexible and leads to design flaws that are discovered too late to do much about them. Usually even in a waterfall approach I'd suggest prototyping where the high risk coding tasks are actually implemented during the design phase to a large enough degree to confirm that they can be accomplished and will work as desired.

Agile approaches suggest you should only design as much as you need to get started, and then do a bit more design later when you find it's needed. This mixes coding in with design, and makes for a much more flexible approach. However, this is often misinterpreted to mean that "no design" is done, or large parts of the design are not thought about until it's too late - this should not be the case. You should design the overall structure enough that you understand how to proceed, and that the small parts of the design that you have not specified precisely are simple enough that you know you will be able to design them later without compromising the final product.

So whichever way you go, you need to plan well enough that you know where you are heading, be flexible enough to change direction when it is needed, but write some code (prototype or final code) during the process to help guide your design. And be prepared to refactor and rewrite parts of the program if they prove inadequate.