Visualising Trade-Offs in Software Development
Marshmallows for Product Managers
You might have heard of the famous Stanford marshmallow experiment from 1972, where children were given a single marshmallow on a plate, with the promise of a second one if they could wait some time before eating it. If the child couldn’t bear to delay gratification for 15 minutes (and many could not!) they would forfeit the second marshmallow
This experiment highlights something we all understand intuitively — sometimes it is difficult to forgo short-term gains in exchange for some delayed, but much greater, long-term gain. Even when the benefits are clearly defined and unambiguous, like compound interest on retirement savings, we often find ourselves instead prioritising the here-and-now. I suspect this is why AfterPay is so popular among jaded millennials, myself included.
The tech-debt bog
The speed at which a company can develop software is a function of resources, requirements and tech-debt. That third parameter slowly and inevitably increases with time, and like driving through a muddy bog, the deeper in it you are, the slower you move.
This leads to a common dilemma for PMs:
Continue delivering features (albeit slowly, due to accumulated technical debt)?
OR
Press pause on delivering features and focus on addressing the problem, which will increase our velocity long-term?
The right answer varies business to business, and also changes with time depending on available resources, level of tech-debt, etc. The answer today may be different to the answer in 6 months time, and it’s likely to create some tension within the business — where the priorities of different functions pull the decision-maker in multiple, competing directions.
Perhaps your devs are fully on-board with multiple sprints dedicated to code refactoring and clean-up (“it will make my life so much easier going forward”), while other stakeholders may balk at the idea of an extended feature drought (“how do I justify delaying this feature yet again?”). If you’re the one tasked with deciding, how do you choose a path? And perhaps more importantly, how do you convince people that your choice was the right one?
Quantify and visualise the trade-off
While it may be much easier to argue for one option or another in the abstract, it is often said “a picture is worth a thousand words” — so let’s draw a picture.
Consider the current situation
We can visualise Option One (the path where development continues, but slowly due to tech-debt) by drawing a simple line using the equation:
y = mx
… where y is your measure of the outcomes/output (for example, “average number of features delivered”), x is your measure of time (e.g. “months”), and m is your current speed (“the number of features delivered per month”). These are just examples, use whichever measures make the most sense for your given situation.
Using this equation, you can very easily calculate the expected number of features delivered after x months, by multiplying by m. If, on average, you deliver 2.5 features per month, in 24 months you should have delivered 60 features (2.5 multiplied by 24 = 60).
Consider the alternative
Drawing the second option (the one where development is temporarily halted) is slightly more complex, since we have a few extra parameters to consider.
First you need to estimate how long the “pause” will last — let’s call this parameter p. This will depend on your particular situation, but I’d suggest leaning towards over-estimating here (you’ll see why later).
For this example, let’s say it will take 4 months to sort out the tech-debt (therefore p = 4), and during that time you expect zero features to be delivered (m = 0). Because anything multiplied by zero equals zero, this period of time looks like a horizontal line from the origin to where x = 4.
It may be the case that some proportion of the team can continue to develop new features while the tech-debt is being addressed. If so, you can adjust the slope of the line accordingly (see left). You can even use a negative value to represent work that will need to be re-done (i.e., you’ve gone backwards a bit) as a result of the pause. In any case, make sure to cut the line off at p.
Finally, you need to estimate your speed after the pause. This is challenging because you’re essentially trying to predict how the work done during the pause will change productivity in the future. I’m not going to get into the details of how to find this number (maybe in a future post if anyone is interested?), but again I’d suggest using a conservative estimate here.
For now, lets say you’ve spoken to your tech leads and they expect that after the tech-debt is dealt with, average development time per feature should halve (therefore, speed should double). In this scenario, the slope of the line, m, is double that of Option One (2 * 2.5 = 5, so m = 5).
Draw this line originating at the end of the line representing the pause, and you should see that it crosses over the line for Option One — this is the “break-even point”.
In the chart above, you can clearly see the short-term losses associated with Option 2 are paid back in full at the 8 month mark. From that point onwards, the increase in speed compounds.
This is particularly dramatic when taking the long-term view:
At the 3 year mark, choosing Option One would result in around 90 features being delivered. In contrast, choosing Option Two would mean developing 90 features would take only 22 months (just under 2 years), and at the 3 year mark, 160 features will be delivered.
In this example case, the long term compounding benefits are dramatic. This is why earlier I suggested using conservative estimates. Another approach is to draw two lines for Option Two— a “best-case” and a “worst-case” scenario — and consider the range of possible break-even points when making your decision.
So which is the right option?
After visualising both options, you will still need to weigh the costs and benefits before coming to a decision. If your situation requires some outcome before development can resume, then you may need to stick with Option One. If the expected short-term losses can be tolerated, and the long-term gains are attractive — Option Two is the way to go. If you’ve followed these steps and found that the two paths do not cross over (i.e. no break-even point), congratulations! Your decision has been made for you and should be plainly apparent in your chart.
TL;DR:
The closer the break-even point, the stronger the argument for taking Option Two.
If no break-even point exists, choose Option One.
If you’re curious…
I work in the Product Intelligence team at Whispir, and my job is to help our teams make better decisions using my expertise in statistics, neuroscience and data visualisation.
This blog post came into being because recently some of our teams were considering a large technical project which might delay features, and we needed a quick and easy way to consider the options, and communicate the impact. I built a simple trade-off visualisation tool so that teams could “see” the long-term benefits (or lack thereof!) and have a conversation anchored by numbers, rather than gut-feel.
Admittedly, the method I’ve described here is pretty basic, and could easily be extended by adding non-linearities (to account for accelerating/decelerating productivity) or time-dependent confidence intervals (because near-term projections are more reliable than those further out).
However, in the spirit of Tim Peters’ “The Zen of Python”:
If the implementation is hard to explain, it's a bad idea.
