Software Design: Tidy First?

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.

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.

Leave a Comment