How would you balance between designing and (actually) implementing you application_问答_开发者

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 screw开发者_开发问答ed 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

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.

Any kind of programming project is fundamentally an iterative process. Whether you've got a single programmer doing everything, or a huge team split into smaller groups handling bits and pieces of the whole.

It's like the old military maxim: No battle plan survives contact with the enemy. Even the most minutely detailed and specific development plan will hit some bumps in the road which require changes in parts of the project. And if clients have input into the project as it hits various milestones, they'll ALWAYS want changes, or want to scrap things and start from scratch.

Even the feedback between team members will cause changes. The database schema architect may have come up with a brilliant schema that looks absolutely perfect on paper, but performs like a brick when actually implemented. The coder could have implemented an absolutely gorgeous algorithm for some facet of the program, but it ends up sucking too much RAM and you end up going back to an uglier but more efficient method.

Doesn't matter what development method buzzword you end up using - things will change, and you just have to adapt. Find something that works for you and your team, and go with it.