Quality isn't the cost. Poor quality is.

Teams often treat software quality as a trade-off: spend time cleaning up the code, or spend that time delivering features.

Martin Fowler argues that this framing is fundamentally wrong when it comes to internal quality.

Users may never see clean architecture, good modularity or maintainable code directly. But they experience the consequences. Poor internal quality makes every future change harder. Understanding the code takes longer, changes create unexpected problems, testing becomes harder, and delivery gradually slows down.

That makes internal quality less of a technical preference and more of an economic one.

The article was published in 2019, but it feels even more relevant now. AI coding agents can generate working software faster than ever. The interesting question is no longer just how quickly we can produce code, but how easily teams will be able to understand and change that code later.

A useful read whenever the conversation becomes “quality versus speed.”