Does it make a difference? Can spending time on it be justified?

It’s hard to argue if it matters for a company directly, if it affects its bottom line, which is by and large the main question for most companies. While an argument can be made that thoughtful design makes it easier and faster to modify, extend, and scale software, it’s hard to measure how much this impacts a company’s profit versus an approach of carelessly written code due to the lack of quantifiable evidence.

On the other hand, building as fast as possible with minimal resource expenditure seems like a no-brainer for the goal of maximizing profit, but these tactics directly conflict with the slower, more long-term approach of software design. Does software design then actually hurt profit by standing in contradiction to these tactics, and can we conclude that software design shouldn’t ever be considered because it makes no tangible difference and only hurts company outcomes? Is there maybe some example of when software design does make a positive difference in outcome that we can use as a starting point for rationalizing its existence?

The first thing that comes to mind is contract work. When building software for a client, there’s an understanding that, once built, you hand over the software to the client. The client inherits the software, so if it’s not designed well, they inherit its fragility, rigidity, and issues. In this case, good design has a direct benefit on the long-term outcome for the software and the client inheriting it.

Abstracting this example a bit, it seems anytime software is inherited or changes hands, good design is a worthwhile investment. So then, when does software change hands? Is it only in the case of contract work? It’s obviously much broader than that: software inheritance happens when a new developer onboards to a team, a developer is assigned to extend/modify the functionality of existing software that they didn’t build, an engineer on support needs to understand a piece of software to triage a bug, and so on. Even these few examples occur frequently enough to make a case for spending time on good software design, because on the side of well-designed software the experiences of the people affected by it are intuitive, simple, pain-free, and empowering, and on the other side, they’re frustrating, demotivating, difficult, and never-ending. This makes it feel like good software design isn’t just a self-indulgent activity but makes a real impact, no matter the company or product.

While it may not matter for the company’s goals directly, good design matters to the people working with and inheriting software. The fellow engineers who don’t have to wake up to alerts, or spend weeks reverse engineering a system with no documentation in order to extend its functionality, or deep dive to understand a system to triage some bug, or newcomers who have a faster and easier time onboarding, or the entire development team who is able to build faster and with more confidence. It may not make a direct impact on profit, but it makes an impact on the number of headaches for years to come. If we assume that empathy is a worthwhile value to uphold, then the benefits of good software design are self-evident, and maybe empathy becomes a measure of how good a design is. The more people a design impacts, the better it is.

These smaller impacts of good software design build up to the larger nurturing of a tech culture of collective ownership and consensus, a culture ultimately rooted in empathy. The question then becomes, do empathy and healthy culture matter? While I can’t speak for a company’s leadership, I can say for myself that empathy is a worthwhile value and aspiration and has a ripple effect on the people around me, so I will continue to fight for and champion good software design as one way of serving and supporting my fellow peers and making the impact I can.