Top Down v. Bottom Up design approach

Question

Duplicate: http://stackoverflow.com/questions/130933/design-coding-top-to-bottom-or-bottom-to-top

I think I have found in my recent experience that I design software differently than most of my peers. I tend to take the incremental bottom up approach after gathering enough requirements to get a high level idea of the components in the software.

So, in the case of designing an interface that would support multiple concrete classes...I would take a look at what is common to each specific concrete candidate, asking how would I get the job done for each concrete (while thinking about being robust for future concrete). Then I take that set of commonalities and make an interface, which I believe is a "bottom-up" approach.

In the case of a top down approach I would believe that the designer would look at the client side of the interface and how a client would interact with the interface and then try to implement the concrete classes.

So I can see advantages and disadvantages of top-down / bottom-up. I just would like to know which is more efficient and provides a better result based off of your previous experiences?

Note: I'm not talking about development methodology (agile, waterfall, etc.), I'm talking about design approaches.

Answer 1

I believe that with good software designers (and in my opinion all software developers should also be software designers at some level), the magic is in being able to do top-down and bottom-up simultaneously.

What I was "schooled" to do by my mentors is start by very brief top-down to understand the entities involved, then move to bottom-up to figure out the basic elements I want to create, then to back up and see how I can go one level down, knowing what I know about the results of my bottom up, and so forth until "they meet in the middle".

Hope that helps.

Answer 2

It depends on the problem.

If you know what the problem is [allow customers to see online bank statements], and how to solve it then use a bottom-up approach. Analyse each step, group these together by area and develop a solution. Project plan based.

If you have a vague idea of the problem [allow field agents to communicate via a distributed offline/online wiki] then a top-down approach would work better. Look at the over all problem and what steps can be used to solve them. Trial and error. Agile.

Answer 3

There is no perfect way to design software. No approach will guarantee the perfect design.

You have to view the problem in different ways when designing a solution for it, and when you have a design you should look at it different ways as well. You won't come up with the same design if you approach it from the top as you would if you approached it from the bottom. So do both, and pick and choose the advantages both methods give you.

Understand the problem at its highest level and work your way down through the solution, identifying parts where the details may end up changing the design (details you should approach from the lowest level and work your way back up). Keep iterating through all of the components of the problem until you have a design that's good enough to work with.

Code Complete chapter 5 can really help hammer out the details of what I'm saying here. I suggest you take a look.

Answer 4

I'm not sure I have understood your question correctly, but if I have, you're asking for pros/cons with building an application and then it's interface versus building an interface and then building the app to make it actually do stuff.

I would say much of the answer depends on whom you're developing/designing for. Is your goal to provide a cool and (perhaps) useful app to the users? Start with the UI. Or are you trying to build an interface to a business system (that might already exist), or to complete tasks that are already being executed in other (less efficient) ways? Start with the tasks.

Answer 5

Bottom-up is what a lot of us code. Not through choice but through intellisense. Petzold wrote an article about this here.

In practise I think you'll find the majority of architects design this way. I personally don't think i've ever seen anyone do the design the other way round (concrete to abstract).

Sure, requirements are concrete-ish but one generally uses requirements to direct the abstractions and define the purpose and intent of the software.