Fool Proof Design

Why do we change the design of the software? So we can change the behavior of the software more easily. If we didn’t need to change the behavior, we wouldn’t need to change the design (unless we’re changing the design as a learning exercise or because we have nothing better to do).

We’ve talked frequently about the cost reduction aspect of design change, but always from the perspective of making the changes we want to make. There’s a lurking cost, however, that I’m starting to realize deserves more attention.

Errors = $$$

The system behaves however it behaves. We want it to behave differently. We change the design so changing the behavior is cheaper. Either this pays off or it doesn’t (we mostly want design changes to pay off).

Here’s the alternative cost saving. The system behaves however it behaves. We want it to behave differently. We change the behavior. Something goes wrong. Ouch! 🤕

The tidy first/software designer response goes—we see the potential for errors so we improve the design to eliminate the source of errors (more about this later). Now when we change the behavior, we don’t make the error, we don’t end up on the front page of the New York Times, we don’t get sued, the team stays confident, users still trust us, & we saved a bunch of money.

Example: Privacy

A large software company develops many products. Each team cares about privacy but they code their own privacy code. Privacy code tends to be fiddly with lots of corner cases. Mistakes are made. Journalists enquire.

Software design to the rescue—we’ll build a single abstraction that everyone can use for privacy. The typical S curve ensues—a few usages of the new abstraction, then a flood as folks get comfortable with it & the abstraction grows in capability, then a long tail.

Some cost saving from the new privacy lens comes because feature developers no longer have to code their own privacy code. Much of the savings, though, comes from errors not made.

A few holdouts claim that their oh-so-special feature needs bespoke privacy code. Errors ensue (those pesky corner cases). Journalists enquire. The dictate comes down—no more exceptions! If you need functionality the central abstraction doesn’t offer, then add it to the central abstraction.

Adding functionality to the central abstraction requires donning robes, burning incense, sacrifices. A mistake there is now a mistake for everybody.

Justification

We’ve just started talking about the justification for software design as a way to reduce the cost of implementing features. Software design is hard to justify because the intended effect is delayed & negative. It’s the money we don’t spend on the next feature or the five after that makes software design economical.

Software design to reduce errors is even harder to justify. The return on investment comes when we don’t have to spend time/money/energy/confidence/trust repairing errors that didn’t happen.

Next?

• Collect stories of software design as error reduction.

• Explain the principles of error reduction. For example, I think there is a class of errors resulting from data becoming inconsistent & design responses to prevent this.

• Go back to my insurance friends for an economic model for software design as error reduction, much as we have explored discounted cash flow & optionality as economic models for software design as feature acceleration.