Top-down or bottom-up design?

Question

There are basically those two approaches to designing a system. What are the advantages and disadvantages? When should I use which? Should I combine those approaches? How?

Answer 1

Roughly speaking, top-down comes from a decomposition of the problem space into sub-problems, while bottom-up comes from organizing parts of the solution space into larger chunks.

To be able to effectively use top-down, you need a very solid understanding of the problem, i.e. have solid requirements in hand. For bottom-up to be effective, you need to be solving a 'standard' problem whose pieces are well-known, but where the exact assembly might need some experimentation before you get it right.

You should read Parnas' brilliant paper A rational design process and how to fake it for much more on this issue. The answer is: use both, as appropriate. When you're done, make it all look like (in your specifications, design documentation and user documentation) as if you had done everything top-down.

Answer 2

You should also take a look at the 'Slicing the cake' principle from the agile community. This principle forces you to focus on adding business value for the user with every iteration of your application. You try to design and implement a vertical slice of your application and deliver it, then focus on the next slice etc.

Here is a link that explains the principle in more detail http://blog.energizedwork.com/2005/05/slicing-cake.html

Answer 3

I think your question deserves long and articulated answers. I suggest to read an old article of Martin Fowler (cfr. "is design dead?") which talks relations about upfront design and agile techniques (http://martinfowler.com/articles/designDead.html)

My experience is to have always a blue print architecture of the modules, interactions between components of the system. Having this blueprint (which in some projects can be high level), I start designing/developing modules/components. Some of these can be developed also bottom-up.