Here is the problem, an enthusiastic man wants to build an app, however he only knows roughly how the app should work. There are a lot of details he didn't know.

How does he design his app?


Do not design, but just code the most important first & test to see how it goes then modify gradually. After the highest priority function finished, he can move to the next priority function. Bottom-up Approach.


Keep thinking until he realized all the details then design a complete app before actually coding. Top-down Approach.


Combine of both option1 &2, ie he can design some basic function first then start coding even he didn't realise all detail then modify accordingly.

It's very hard to know all the details right at the beginning cos we are human & we can't predict the future.

So i vote for option1 or 3. But it's kind of painful if you has to change ur code if you're missing the details. A lot of things has to be changed. My instructor in university say he always prefers top-down approach cos he believed it better.

However, i think build a software just like u live a life, you never know in advanced what will happen in the future, so option1,3 could be the better one.

What is your solution?

  • 2
    Voting to close as too broad. All of these are fine, and it depends on the problem at hand. I'm not going to prototype the space shuttle for example. How to create software is a super broad topic; not something we can address succinctly here. – Telastyn Mar 16 '14 at 2:54
  • To clarify are you trying to design an app's UI? or the model and database structure? – scunliffe Mar 16 '14 at 3:41
  • design the whole app – Kiti Mar 16 '14 at 4:55

What you are describing are different project management approach - Option#2 is a waterfall approach, where you first describe the product, then you design it, then you implement it...

Advocates of Agile software development argue the waterfall model is a bad idea in practice—believing it impossible for any non-trivial project to finish a phase of a software product's lifecycle perfectly before moving to the next phases and learning from them.[citation needed]

For example, clients may not know exactly what requirements they need before reviewing a working prototype and commenting on it. They may change their requirements constantly. Designers and programmers may have little control over this. If clients change their requirements after the design is finalized, the design must be modified to accommodate the new requirements. This effectively means invalidating a good deal of working hours, which means increased cost, especially if a large amount of the project's resources has already been invested in Big Design Up Front.[citation needed]

Options #1 and #3 are very simplistic descriptions of a more Agile approach, though these approaches tend to be more formal than "let's hack through it!"

I believe the enthusiastic man should first understand fully what problem he wants to solve. Then, an approach which resembles Option #1 - a Behavior Driven Design - might work for him, where he writes the main User Stories for his solution, describes them, then implements them in short-iterations.

This will produce a quick MVP he can assess, quickly decide if the product is indeed viable, and if it is, start adding more user stories for another iteration...

| improve this answer | |

Most software development involves a combination of top-down and bottom-up approaches. Personally I think it is very poor practice to start coding before you have designed the big picture. You will end up with a bunch of pieces that don't fit well together. Start by identifying your major components and their interfaces, and how they interact with each other. In OOP you should have all your important class interfaces designed before you start to write code. After you start coding you will surely add more helper classes which just help keep the code neat, but that's OK. If you program to an interface, not an implementation then you can sculpt out the entire flow without implementing any of the classes. You can start implementing each class one at a time and have the others return mock values until they are ready. This way you always have a complete picture.

As you said, you can't know 100% every curve ball that will be thrown which is why top-down and bottom-up are used together. Design your program, start writing, and if you need to go back to the drawing board because something doesn't fit right then that's OK.

| improve this answer | |
  • But what about you build a website that you knew before? Ex, you knew every details of how stackoverflow works, & you want to build exact same website. In this case, do u use topdown approach? – Kiti Mar 16 '14 at 3:10
  • 1
    form your answer, i think The BEST option is to use Top-Down as much as possible until you can't figure out more then start to code bottom-up. – Kiti Mar 16 '14 at 3:13
  • @Kiti Depends entirely on the developer and general needs. There is no silver bullet, which seems to be what you're looking for. – Izkata Mar 16 '14 at 4:51

Not the answer you're looking for? Browse other questions tagged or ask your own question.