Boundary Conditions

"The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair." - Douglas Adams

Recently Deutsche Bahn had a flurry of self-inflicted misfortune as a result of a combination of cost cutting and poorly defined boundary conditions.

Boundary conditions are the constraints and assumptions that shape a design, strategy or plan.

For example, when designing software one of the questions the designer has to ask is, What could go wrong? This is a pretty crucial question because the user may not understand how to navigate a particular process, or deliberately try to get around a constraint in the system.

The software designer's job is to gently herd the user into the right direction, where 'right' is defined as 'transaction completed correctly, no risk to security, no bad data and no one throwing their computer across the room.'

Think of the answer to the question, 'What could go wrong?' as the leading question you ask in order to define your boundary conditions. Your design must reflect these because too often what could go wrong does go wrong.

Just to clarify, this does not mean you design for everything that could go wrong because that would be insane. What it means is that you design to avoid the most likely and/or critical failure scenarios and have a backup plan (such as a correction function or an undo button) for everything else.

I'm oversimplifying but it's hard to unpack years of lessons learned from software design in one sentence.

So, getting back to Deutsche Bahn, they diligently defined boundary conditions under which their air conditioning unit would function properly. Unfortunately, they designed their system for a temperature that is frequently exceeded during the summer.

There were financial reasons for doing this, of course, but the bottom line was that the air conditioning would stop working as soon as it actually got hot.

Then they skipped some maintenance checks to save costs.

Finally, they made a mistake that as a system designer makes me cringe - there was no backup plan built into the system.

Personnel weren't trained in what to do in the case of extreme heat. Windows couldn't be opened. Passengers (including infants, elderly, and all those poor people in business suites) sat trapped in moving cars at temperatures of 50 C and upwards.

I wonder what that fiasco is going to cost.

When designing software or defining business strategy, it's imortant to define appropriate boundary conditions that consider costs as part of the equation.

But don't stop there:

Try to identify what can go wrong when you cut costs. . .

and what it might cost if something does go wrong in terms of money, reputation, human life, etc. . .

and whether the cost cutting really makes good business sense when you get right down to it.