Why 'It Works' Is the Wrong Metric for Software Quality

This piece examines a structural blind spot unique to software engineering: the absence of physical feedback. A bridge failure is traceable and measurable against every bridge that didn't fail, but software built on flawed abstractions compiles, ships, and passes tests just as reliably as software built correctly. As a result, architectural mistakes rarely get diagnosed — blame falls on domain complexity, shifting requirements, or careless predecessors instead of the actual structural decision that caused the problem.

The argument centers on how 'does it work' became the default quality metric, and how that metric conceals decay. A system can satisfy its entire backlog while business rules are duplicated across layers and encoded inconsistently in multiple places — nothing looks broken until a new requirement has to touch all those copies at once. The proposed fix is to stop evaluating behavior and start examining mechanics: the relationships between domain concepts, where responsibilities actually belong, and whether rules live in one findable place rather than being scattered implicitly through the codebase.

Using a library lending example, the author shows that a loan should be modeled as its own event with its own lifecycle, not as a property of the book — a distinction that produces no visible bug until the system needs to answer questions about lending history. The piece ties this back to Fred Brooks' essential-versus-accidental complexity, arguing that the real risk isn't which framework or pattern is chosen, but whether the actual shape of the business problem is represented faithfully.

For engineers, the practical takeaway is to move code review and architectural discussions past 'it works' and toward whether the mechanics of the domain are correctly located, deduplicated, and legible to someone who didn't write them.