How Cost of Delay Helps Make Better Investment Decisions
When it comes to software development, businesses tend to make investment decisions based on cost, rather than payoff. In this post, we use Cost of Delay to calculate payoff as a function of team configuration and time.
An example case
Let’s say that you have this new feature fleshed out and ready for development. The senior developer that you worked with indicated about 2 humanweeks in initial development, before review and corrections.
However you are considering alternative team configurations, and you want to calculate the most cost-effective one, based on historical data.
Two freelance developers are currently available to work on this feature for $100 an hour.
The team configurations that you and the developers are considering are:
- One developer working solo, the other doing code review,
- Both developers working together (pair-programming),
- Both developers working in parallel, dividing tasks and peer-reviewing each other’s code.
Historical data
You have run some experiments in the past which yielded the following statistical data:
- Coding individually for two weeks creates some defects which require two days of corrections,
- Code review for two weeks of work takes half a day,
- Pair-programming shortens cycle time by 30% and prevents major defects, so code review and corrections are not necessary,
- Dividing tasks generates 30% overhead during initial development (consultation, waiting times, context switching).
Option 1: One developer, one reviewer
| Cycle time | Dev time | Dev cost | ||
|---|---|---|---|---|
| Initial dev | 2.0 wk | 2.0 wk | $8,000 | 1 dev, 2 weeks |
| Code review | 0.1 wk | 0.1 wk | $400 | 1/2 day |
| Rework | 0.4 wk | 0.4 wk | $1,600 | 2 days |
| Total | 2.5 wk | 2.5 wk | $10,000 |
Option 2: Two developers pair-programming
| Cycle time | Dev time | Dev cost | ||
|---|---|---|---|---|
| Initial dev | 1.4 wk | 2.8 wk | $11,200 | -30% cycle time |
| Total | 1.4 wk | 2.8 wk | $11,200 |
Option 3: Two developers dividing tasks
| Cycle time | Dev time | Dev cost | ||
|---|---|---|---|---|
| Initial dev | 1.30 wk | 2.6 wk | $10,400 | +30% overhead |
| Code review | 0.05 wk | 0.1 wk | $400 | |
| Rework | 0.20 wk | 0.4 wk | $1,600 | |
| Total | 1.55 wk | 3.1 wk | $12,400 |
The most cost-effective option
The results do not seem all that different, but option 1 has the lowest cost, and looks like the clear winner.
However, it is also the option with the longest cycle time, so you ask senior management if they are in a hurry with this new feature.
“If we are in a hurry?!”, they say, “You bet!”
So it looks as if we’re not done yet — we need to somehow include time in our assessment.
Establishing Cost of Delay
In order to put a price on senior management’s hurry, you work with them on a P&L (profit and loss) statement for this feature.
They point out that there is a window of opportunity worth $260,000, which closes 26 weeks from today. The income stream is pretty much linear, so $10,000 for every week.
The Cost of Delay is therefore $10,000 per week. Now that you’ve put a price on time, let’s see if that affects our preference for option 1.
The option with the highest payoff
With Cost of Delay, the picture starts to look a little different:
| Dev cost | Lead time | Delay cost | Payoff | |
|---|---|---|---|---|
| Option 1 | $10,000 | 2.50 wk | $25,000 | $225,000 |
| Option 2 | $11,200 | 1.40 wk | $14,000 | $234,800 |
| Option 3 | $12,400 | 1.55 wk | $15,500 | $232,100 |
Option 1, our original preference, turns out to have the lowest payoff. And option 2, which we thought was 12% more expensive, turns out to have the highest.
We have a new winner!
Conclusions
In order to make smart investments, we need to know not just the cost, but also the return. With Cost of Delay, we can do exactly that.
Do not interpret the numbers above as a recommendation for pair programming per se; this article is just demonstrating a calculation method. You need to collect your own data and run your own numbers.
Using Cost of Delay has more benefits; it can also be used to prioritise features and to make day-to-day decisions during development. More on those later!