Top Down Or Bottom Up Development Order?

               It has been a while since I have posted anything in my blog, so here goes the topic of the day - top down or bottom up development order. Usually, most of the companies develop software following either one of these development orders. Since both of these development orders have pros and cons, one should pick the right development order that fits their situation. Companies/teams usually consider the answers from the following questions before deciding the development order they want to follow:

·        how clear and concrete are the requirements?

·        how far is the deadline of the project?

·        which software development methodology is your team following - agile or waterfall?

               Let's begin by discussing briefly about what is top down and bottom up development order. In top down development order, developers develop the overall framework of the software first and then they zoom into the concrete features later. Usually, developers write all base classes, common interface and abstract classes first and then they add concrete and derived classes later. This means  in top-down development order, a working version of system is designed first, which provides overall behavior of the system and then developers work towards narrowing down the details about the subsystems. The main advantage of top down development order is that the overall behavior of the system is known beforehand, so it provides an ample opportunity to developers and testers to test many scenarios to catch error before designing subsystems or adding more features to the system. If your team uses test automation to test the software, then testers can write the overall test framework for the system first and as developers continue to add sub-systems, testers can simultaneously expand the test framework to cover those newly added sub-systems. The only catch here is that in order to adopt top-down development order, detailed requirements should be known ahead of time, which may not be plausible in agile. If you write all common interfaces, abstract classes, and base classes first and then when you are ready to add concrete classes, what if the requirements of the system change? You have to rewrite all those interfaces, abstract and base classes again.

               In bottom up development order, developers start with writing subsystems first, and eventually they integrate all subsystems to form the entire system. Usually, developers write concrete classes for subsystems first.  Since all these subsystems aren't integrated until all main classes are developed, performing integration testing can be a challenge. Developers/testers can start testing subsystems, but testing subsystem is no better than doing unit testing. There is always a risk that once you combine all subsystems at the end, your system might behave differently. Therefore, exhaustive integration tests should be conducted at the end. Designing test framework for integration tests can be cumbersome since developers/testers write large number of methods to test subsystems, and after combining all these subsystems together, they have to write another testing framework for integration tests. If there is a time constraint for release, one can easily miss exhaustive integration tests. Bottom up may be the best fit in Agile workflow because changes in the requirements may not warrant rewriting lot of code here.

               Top down and bottom up development order aren't only applicable in software world as they can be used to design anything. Imagine building a house. How do building contractors build a house? They start building the overall structure of the house first, then go on designing the rooms or they start designing different rooms first and then work on structuring the overall building? Like software, answers to these questions depend on the requirements of the owner of the house. Does the owner of the house have pretty clear idea regarding how does he/she want his/her house look like, how many room does he/she want, etc? or he/she wants to decide once building contractors have built the foundation of the building first?

               You might be wondering now regarding which development order is the best. I don't think there is a correct answer to this question. If you have a clear and defined requirements ahead of time, then you should go with top-down model. If the requirements are not known ahead of time, then I would suggest to go with bottom up development order. Also, from my experience,  I personally feel that when you have enough time to develop a system, then you should go with top-down development order . Bottom-up development order comes in handy when there is time constraint. From testing perspective, I would suggest to choose top-down development order as it helps to discover errors of the overall system earlier.