I’ve found an interesting analysis of roller coaster’s safety systems in Theme Park Design: Behind The Scenes With An Engineer book by Steve Alcorn.

It’s easy to imagine what happens when roller coaster’s breaks fail. Immediately, lots of guests are in danger.

There’s no room for failure in a roller coaster car.

Amusement rides engineers use an interesting method to minimize the probability of breaks failure. The idea is simple. Pneumatic breaks require air pressure to release, not to break.

In other words, the default state of the mechanism is to clench the break pads, making it impossible for vehicle’s wheels to spin. Only when the mechanism operates normally, the breaks are released and the vehicle can start the ride.

When the mechanism breaks down, it naturally goes back to its default state and the wheels are blocked.

We can borrow the idea of “release, not break” and use it in software development, too.

Minimizing failures in development

Software suffers from different set of failures. Every single piece of code will fail one day. One of the things we can do is to minimize the probability of failure.

Let’s assume a simple switch statement that prevents from deleting a user with administrative rights.

switch (user.role)
{
	case 'owner':
	case 'admin':
		can_delete_user = false;
		break;

	default:
		can_delete_user = true;
		break;
}

if (can_delete_user) {
	user.delete();
}

There’s a ticking time bomb inside that code.

It’s because the default state of this code is: “user can be deleted”. We prevent from deleting the user only in particular cases. So when we decide to add another role (such as a “supervisor”) and the developer forgets to update the code, the “supervisor” is not prevented from being deleted.

A better attitude is to set the default state to “user cannot be deleted”:

can_delete_user = false;

if (user.role === 'normal') {
	can_delete_user = true;
}

if (can_delete_user) {
	user.delete();
}

This way our system deletes the user only when intended. Future code modifications have low probability of breaking the intended behaviour.

Conclusions

The example shows two opposite attitudes to solving the same problem. Software developers should always try to pick the one that lowers the probability of system’s failure.

Oh, and there’s one more interesting insight about roller coasters. Most of them intentionally have just a single train. In case of breaks failure, the train doesn’t hit another one that waits for passengers on the station.