Good software design is fundamentally about preserving the ability to change code cheaply over time. Using a restaurant billing system as a running example, the post demonstrates how code accumulates 'friction' as requirements grow — booleans spreading across methods, implicit dependencies, and ballooning class responsibilities. Sandi Metz's TRUE acronym (Transparent, Reasonable, Usable, Exemplary) is introduced as a practical compass for evaluating design quality. The post also addresses the tension between technical debt (solving problems too quickly without structure) and over-engineering (anticipating the wrong future). The key takeaway: start simple, wait for concrete pain signals before redesigning, and use design principles and patterns as tools rather than laws. Code metrics are useful for detecting problems but don't guarantee good design.
