Technical Value is Business Value

When software developers are focused on good design — focused on taking the time to build a system the right way — they are focused on delivering business value for their customers or stakeholders.

They want good design because they know that in the medium and long-term a system with good design is easier to support and extend. This has clear business value — you can do more new stuff (features) for less money and you can fix problems (bugs) for less money.

More stuff for less money is good business value. In this way, technical value (good design and elegant coding) is business value.

A system with poor design may get more features built more quickly, but before long productivity will break down as the absence of plan results in fragmentation and chaos.

So in this way, you may get a quick hit of productivity, but in the long term you spend much more to get less which is bad.

There are times in every project where you reach an inflection point and what I described above needs to invert, temporarily. See this earlier article on the topic of technical debt and why sometimes the two can be at odds.

During the inversion, you take on technical debt to deliver some quick hits, once the underpinnings and architecture are in place so that you can ship a product on time to the marketplace.

Overall I think it is important to remember that the title of this article is true — in the long term good design is business value. Though sometimes you suspend that temporarily to deliver.

Sometimes business people want result right now and impatience with delivery is seen as a virtue. It can be. If it is a temporary inversion and not a long-term state of affairs.

It can be a real hindrance to long-term value if that state of affairs is chronic and without respite.

The decision to switch from the long-term view (important at the outset and through most of the life of a project) to the short-term view (often important at the end of the project, to deliver on time) is an emotional one.

People don't want to stop designing and they don't like the idea of taking on technical debt. However, it can't be avoided.

Your job as a software development leader is to listen and guide your team through this transition, AND to guide the business back, once the release is done.

Be aware of the emotions and motivations on both sides. Make the smart decision to ship. Also, make the smart decision to switch back and pay your technical debt when the next phase begins.

I think that we need to recognize two important things:

1. A request to finish fast and on a timeline can feel arbitrary to people you need to articulate why.
2. A request to finish fast and take on technical debt can also appear to be a request to stop delivering business value and do a shoddy job, you should avoid phrasing things so that it sounds this way.
3. A choice to finish fast is a choice for the business value of now versus the business value of later which can be called many things: time value of money, a bird in the hand is worth two in the bush, or "we need to close this account". This can be a good and smart decision, but it is a decision with trade-offs. Acknowledge the trade-offs and press forward.