Part 2: Identify critical design elements – early

Breakthrough.

That’s the word that comes to mind after a very long (and at times very vocal) design session that ultimately led to good design decisions.

Why was the decibel level a little higher than normal?

The current design was based on the aggregate ‘weight’ of over 500 functional requirements, to be delivered in 6 major releases.  There were additional 300+ requirements in the pipeline but were not yet discussed in detail.  Also – the current design already had a number of known items that concerned everyone in the engineering team.

The team faced a decision point:  do we invest time and try to understand if future 300+ requirements may substantially influence current design?   The upside – the design will accommodate future requirements and reduce the risk of refactoring.  The downside – missing time with the families …

It turned out that some future requirements indeed had a significant impact on the current design.   In fact, had the team decided to develop the next 6 major releases based on known 500+ requirements, at some point the probability to completely redesign several critical components would be 100%.  Even more time would have to be spent with fellow colleagues and not families in this case.

The breakthrough was achieved by going back to an example that I used in the past to illustrate how important it is to identify critical design elements as early as possible, even at the cost spending a little more time upfront.

Let’s assume there are separate design teams working on these 2 problems:

A. Fly from New York to Paris in 3.5 hours

B. Fly tom New York to Paris in 8 hours

The design for Option A would yield an aircraft that looks like a Concorde, while the design for Option B would produce a Boeing 767-300ER (or equivalent). These aircraft could not be more different.

Just imagine if by some sheer chance the team pursued Option B (or Boeing 767-300ER) design as an option to fly from New York to Paris in 3.5 hours. It’s impossible for Boeing 767-300ER to accomplish this because of several intentional design decisions made very early in the process: choice of engines, alloys, wing geometry, etc. This is not intended to be a lesson in aircraft engineering but I hope the message emerges.

This example is particularly helpful as an illustration of potential risks: Boeing 767-300ER can never become a Concorde. If the software had fundamental design constraints, these constraints cannot be refactored. Only a new design can solve these problems and making a commitment to a new design is expensive, time-consuming, and at times necessary. But – if this commitment has to be made, going back to the fundamentals of good software design is step one.

Identify critical design elements as early as possible, even if the requirements are not well known. Make the design sustainable over time. Test the design assumptions against known and likely requirements, even if these have to be delivered 12-18 months from now.