The Goals of Software Design

Discussions about software design are sometimes started with attempts at justification: “Why should we do this?”, “What are the benefits?” “What is the purpose?” I think this is a great way to start because downstream decisions (e.g. when you are choosing between design patterns) can often be guided by the goals that are determined at this point.

Some common goals for software design are the familiar phrases of organizing code, reducing technical debt, making code SOLID or cohesive or decoupled, improving maintainability, promoting reuse, or enabling testability. Without a doubt, these are great goals to pursue and would definitely lead to software with much better quality than if software design was done solely for its sake — something, I think, which is equally undesirable as when nobody cares about software design at all.

The thing with goals, however, is that they are also measures and what you measure, you optimize. This makes it really important to be measuring the right thing.

If you have ever proposed to improve re-usability or testability and were then asked why those would be desirable then you may have already gotten a hint. Things like reducing technical debt, decoupling, cohesion, re-usability, testability, etc. are not actually the goals. They might be more sensibly thought of as proxies or principles that are based on the real goal/value.

I once worked with a guy who, despite being a programmer, was so adept at persuading business people in adopting new technologies. I have not forgotten what he said about how he does it. Something about ‘always relating how your idea could increase revenue or decrease costs and that you have to speak to business people through these terms’. More than how to sell an idea, this gave me a fresh perspective on the relationship between technology and business.

Technology often serves a business and a good software design is supposed to minimize the resources required to build and maintain a software system. This has been said by Uncle Bob and this also fits uncannily well with what my old colleague said. The goal — the value — of software design is really just the net reduction of cost. The best measure of a good design is, therefore, the measure of effort needed to adapt software. Over time, increasing effort suggests a bad design and a constant or decreasing effort suggests a good design.

Apparently, there is a predictive component to software design. It is not always obvious which designs could require less effort to maintain in the future. This is where software design principles come in to serve as guideposts or even approximations of the value they are based on. They are not, however, substitutes and I think it is misguided to treat them as though they were.

Software design has a cost. A misguided software design can hurt both the business and the technology. It can make the software more complex without any benefits and ultimately defeat the actual purpose of software design. It is, therefore, important to be grounded in the right values because it will benefit the business and the technology and, maybe, more importantly, it will show competence and professionalism.

Also published here.

Featured image source.