The True ROI of Software Design: Why "Clean Code" Is Not the Final Goal

Discussions about software design often begin with attempts at justification: "Why should we do this?", "What are the benefits?", or "What is the purpose?" I believe this is the correct starting point because downstream decisions—such as choosing between specific design patterns—are guided by the fundamental goals determined at this stage.

Commonly cited goals for software design include familiar concepts: organizing code, reducing technical debt, adhering to SOLID principles, increasing cohesion, decoupling components, improving maintainability, promoting reuse, or enabling testability.

Without a doubt, these are excellent objectives. Pursuing them leads to significantly higher quality software compared to design done solely for its own sake—or worse, ignoring design altogether.

The Problem with Proxies

The issue with goals is that they double as measures. And as the adage goes: what you measure, you optimize. This makes measuring the right thing critical.

If you have ever proposed improving re-usability or testability and were met with the question, "Why is that desirable?", you may have already sensed the disconnect. Attributes like reducing technical debt, decoupling, cohesion, re-usability, and testability are not the actual goals. They are more accurately described as proxies or guiding principles based on the real underlying value.

The Business-Technology Connection

I once worked with a colleague who, despite being a programmer, was exceptionally adept at persuading business stakeholders to adopt new technologies. I haven't forgotten his explanation of his method: always relate how the idea increases revenue or decreases costs. You must speak to business people in business terms.

This went beyond simply "selling" an idea; it provided a fresh perspective on the symbiotic relationship between technology and business.

The True Metric: Cost Reduction

Technology serves the business. Therefore, good software design is supposed to minimize the resources required to build and maintain a software system. This sentiment, echoed by Uncle Bob (Robert C. Martin), aligns perfectly with the business-centric view.

The ultimate goal—the value—of software design is simply the net reduction of cost.

Consequently, the best measure of good design is the effort needed to adapt the software.

• If effort increases over time, it suggests a bad design.
• If effort remains constant or decreases, it suggests a good design.

There is a predictive component to software design. It is not always obvious which architectural choices will require less effort to maintain in the future. This is where software design principles (like SOLID) come in. They serve as guideposts or approximations of the value they represent. However, they are not substitutes for the goal itself, and treating them as the final objective is misguided.

Conclusion

Software design has a cost. A misguided design strategy can hurt both the business and the technology. Over-engineering can increase complexity without delivering benefits, ultimately defeating the actual purpose of design.

It is important to be grounded in the right values. Designing for cost reduction benefits the business, streamlines the technology, and demonstrates true professional competence.