Building a seesaw bridge

Published on 2015-03-16 by John Collins.

Follow @TechLeaderPro

Requirements

Let us imagine for a moment that you are a structural engineer (as opposed to a software engineer), who is given the following set of requirements by a customer who wants a new bridge:

"I want a bridge with a single pair of support columns in the center. These support columns will be attached to the bridge by hinges. The bridge will be slightly heavier on one end, causing it to tilt that way when there are no cars. When a car enters the bridge on one end via the ramp, it will tilt the bridge in the other direction once it crosses the middle of the bridge, enabling the car to exit the ramp on the other side once the bridge is fully tilted"

What the customer is describing here is of course a seesaw bridge:

While such a design can get a car from one side of the river to the other in principal, it is hardly safe. So what to do with such crazy requirements?

Who knows the problem domain best?

The analogy above is one I gave in response to the following statement from a colleague many years ago:

“But the customer is always right!”

There are some industries where that might be true (hospitality, retail etc.), but it is certainly not true in any engineering field. Imagine for example if we were to actually build the above bridge: who do you think would be blamed once cars started to plunge off the bridge into the river below?

Learn to say no

"Implementing customer requirements to the letter is never a good defense when projects fail for technical reasons."

Seesaw bridges are a wonderful analogy for technical debt: if you build it, you own it and must maintain it until you quit (you will also inherit quit a few of these during your career from other engineers who could not say no).

Implementing customer requirements to the letter is never a good defense when projects fail for technical reasons. As a professional, it is your responsibility to tell a customer if their requirements are unworkable or dangerous. That is easier said than done however, as unlike the physical world of bridge building, it is often difficult for a customer to visualize the faulty architecture of a software application.