Shaun MacRae

I’ve heard a few arguments recently siding on either top-down or bottom-up design. I’ve heard some agreement on a need for both. My opinion resides in the second category.

Both are required for different reasons, but both are required in almost every context.

Top-down design is very valuable because it allows us to look at systems with a birds-eye view. This birds-eye view is important for evaluating whether a solution or part of a solution is fit-for-purpose. Solutions that are fit-for-purpose satisfy all of the known requirements for the system, but may also satisfy unknown and predicted requirements. The amount of top-down design subscribed to can be a slippery slope. Predicting requirements before they are known can allow us to build flexibility in early, reducing development efforts later, but building systems for requirements that may never exist does not maximize value.

Bottom-up design is very valuable because it emphasizes modular, re-usable components. Stacking modules on top of modules in layers or piecing modules together in an SOA fashion provides more flexibility because it reduces the need or desire to ‘re-invent the wheel’. Most importantly though, bottom up design forces us to think about the details, and we all know ‘the devil is in the details’. Too much bottom-up design though, can also result in wasted efforts. If modules at the bottom are being designed that aren’t fit-for-purpose, they will either remain unused (maintenance nightmare) or will need to be removed or altered.

It is together in unison, that these two approaches provide us with with the spectrum of analysis required to a) ensure a design is fit-for-purpose, and b) reduce risk and maximize re-use by considering the details of low-level modules.

Practicing these two types of approaches in unison requires a very iterative approach, not just in the software development life cycle (SDLC) as a whole, but even within a particular design phase (which may only be one task in a development iteration).

I usually start with top-down design, considering the requirements and coming up with high-level object models. Not taking this to far, and realizing my ROI, I quickly drill down to the details. This requires a great deal of prototyping and proof-of-concept work, generally resulting in throw-away software, but always resulting in a much better understanding of the problem. At this point, I will step back and review my high-level design. Undoubtedly, I will find it’s not sufficient because initially it is impossible not to gloss over important details that WILL impact the design. Having a better understanding of those details from the proof-of-concept work, I can then begin to polish my high-level design. Typically though, I need to revisit the details in order to validate the high-level design. Once this back and forth process is no longer adding enough value, the work moves through to development. Meanwhile, these mini-design iterations are happening as part of each iteration in the SDLC, so the design changes based on findings during development, and so on and so forth.

Design must be evolutionary, otherwise it can’t improve, and software that doesn’t improve over time will not add value. There are very few contexts that justify the need to design systems in a strictly top-down, up-front (waterfall) approach, and many of the traditional style development groups are incorporating bottom-up thinking and iterative approaches to their designs now as well.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.