Top Down VS. Bottom Up

There are two approaches when it comes to designing software, top down approach and the bottom up approach. The top down approach is when the developer is given a list of requirements and thinks about how the UI will look and how the user will use the UI. The developer will then just start writing code. With RAD development tools like Delphi, VB, etc it is very easy to create a window, start dropping controls on it and start writing code to respond to buttons, menu items, etc. The bottom up approach is when the developer gets a list of requirements and starts thinking about what objects are required to perform the tasks. Thought must be given to what the UI will do and how the UI will interact with the objects, but the UI is only a means to communicate with the core objects. After the initial design the developer will start coding the implementation of the objects and then build the UI to communicate with the objects.

The top down approach is faster. Most prototypes and simple applications are written this way. You can develop it quickly, get feed back and get it to market in a relatively short amount of time. And if the code is not very complicated it is easy to maintain. The problem is when things become more complicated. As time goes on and requirements grow and the amount of code written reaches a level that makes the code difficult to comprehend, maintenance becomes difficult. And if you are working in a team environment probably only the initial developer will be able to maintain the code in a decent manner. Also bug can start appearing because of the complexity of code. Because decisions are based on how the user uses the UI chances are that not all users will agree, some users will want to do things one way while others will want to do things another. This leads to switches and settings in your code that over time can result in spaghetti code, because things are not thought out the end result is very difficult to maintain and error prone. There is also the problem of adopting newer technologies. Because the code base is all tied together chances are that any changes to components will be significant, you will probably have to test everything before you redeploy because you may not know what the impact of the change will be.

The bottom up approach may be slower at the start but more maintainable in the long run. You have to think about what you are doing. If you happen to be wrong you run the risk of wasting valuable time. You also must be careful not to over think things. However, your code will be more maintainable. If you create UML diagrams, this can act as a blue print of your software. Much like database administrators use ERDs (Entity Relationship Diagrams) to view their relationships in their databases, a UML class diagram can show the object relationships of your software. UML can also be used to show the flows of messages through different objects or give a high level overview of how the different sections relate to one another. Further more, as new requirements come in developers are forced to think about how this will affect the core application. Most of the bugs that I see are caused because developers are not thorough when adding new functionality. There are also many benefits to having your UI separate from your object model.
- You can build test scripts to test your object model. This can test the core functionality of your application. Although it can not test everything it can catch some bugs early on and help the developer maintain a reliable code base.
- You can migrate your code. Because you have a separation of UI and objects you have a place to start migrating code. If the UI must change you know that this will not impact the core. Perhaps you are trying to move your application to the web, or perhaps you would like a fancier UI. Furthermore if you would like to move your application to Linux or .NET moving the objects first is easier. Most portability problems are in the UI controls. You may have to rewrite parts of the UI but this is far better then having to rewrite your business logic.
- You can turn your object model into a stand alone API. Perhaps some users would like the ability to create their own UI or may want to integrate your functionality into one of there own applications. This can make your code more valuable and more useful.

I would suggest only using the top down approach in cases when you want to get your software to market quickly and don’t care about long term maintenance. For more serious projects I would suggest the bottom up approach. It may require more time up front however the time saved in maintenance will be well worth the effort.