How do software teams ensure they make great decisions about what to work on? Keeping decisions small is a good first step. The software industry has learned the woes of multi-year projects that result in unwanted products. Small steps with quick delivery of value, lead to improved customer experience, better engagement, higher team collaboration, easier adaptability, and increased market competitiveness.
Occasionally, delivering value quickly is impossible. Customers need a feature that involves multiple teams or services, which can only feasibly be delivered after six months. In these situations, we adapt by investing more rigor into upfront analysis. Business cases or more in-depth research identify the return on the investment and justify the work. Work associated with product features is relatively easy to justify and prioritize, as it is more easily tied to revenue. This includes work that isn’t directly customer-facing, like adding a new database.
Some work is much harder to justify through revenue — refactoring, dependency upgrades, and unit testing are good examples. This work is often small and repetitive but over the course of a project, represents a significant time commitment.
The Challenge with Long-Term Technical Work
A possible solution is to consider by doing this technical work, we create more confidence to add customer features more easily in the future. How much easier though? Will it be delivered 5% faster? 20%? 50%?
It’s difficult to predict, and impossible to measure, as you can’t A/B test feature delivery speed. Theoretically, you could pursue two different approaches to a problem in parallel, but that would require different people to do it, so you couldn’t separate the difference in delivery speed from the individuals completing the work. And if you tried to do it in series, you’d be unable to separate beneficial learnings from approach A in approach B. In the future, there will be an AI solution for this. Two identical AI models could A/B test some solutions, but when they’re able to do that, they’ll be writing the code as well as this blog post!
In the face of revenue-justified feature work, it can be very difficult to prioritize this technical work in a quantitative way. The result? Technical work gets prioritized when it has to be — when it’s too late and there’s a fire.
Making the Case for Long-Term Impact
Nicholas Nassim Taleb, in his book Antifragile, outlines the concept of concave and convex decisions. The former suffer in the face of uncertainty, whereas the latter benefit. People, he says, prefer to consider the ordered, predictable nature of the world around them rather than the scary, unpredictable. In his world of economics, this manifests as a tendency toward stocks that are steady and stable, but suffer hugely in economic downturns over volatile stocks that occasionally skyrocket.
Rather than dig into economics, let’s consider a more relatable idea: flossing your teeth. It’s become largely a cultural norm that brushing your teeth is a good thing. However, flossing hasn’t received the same cultural acceptance, less than 25% of adults floss. Why is this? Because in the short term, the value uplift over just brushing is pretty small. First time flossers also face the prospect of bleeding gums. Despite this, most of us have been advised to floss, initially by caregivers, later by dentists. The reason for this is long-term gains; people who floss are statistically less likely to have gum disease and plaque buildup, and have fresher breath.
Unlike our teeth and flossing, we don’t grow up with people telling us to “write unit tests, do the simplest thing that could possibly work, be considerate of naming.” Many business leaders remain unaware that over the long-term, ignoring these things can lead to problems. And if leadership doesn’t see the value in something, it will always struggle to be prioritized.
Defining and Justifying Quality-Driven Behaviors
How can we define and justify the value of a set of behaviors on a development team that drives quality into a code base, instead of faster short-term delivery. The benefit of which is revenue not lost in the future when feature delivery slows and outages take longer to resolve. And unlike gum disease, typical employee churn means the negative side effects of poor software hygiene won’t necessarily be seen by the people making the decisions.
The solution needs to be approached from multiple angles, including:
Educate leadership on the long-term benefits, referencing books such as Accelerate for evidence.
Give teams the training they need to learn the skills and the time to implement them. A good rule of thumb is 20% of a team's work should be focused on preventative technical efforts.
Create a culture of quality, open feedback, and good software hygiene.
Those three points are simple to write down, but by no means simple to implement. Changes of this size and scale, especially to culture are difficult, but the results are worth their weight in gold. Leadership needs to drive this change, not through mandates but demonstration. By embodying the new culture, it allows others to learn it through osmosis, and start to demonstrate it themselves. And before you know it, people will react to colleague PR feedback about adding unit tests, the same way someone does when they are the only person being offered a mint.
