In Martin Fowler’s DesignStaminaHypothesis, he asks the question of when is it worth the time to design properly, and when it is acceptable to take on tech debt by neglecting design. By neglecting design and long-term thinking, you’re able to take an individual product or feature to market much faster, but you slow down your overall rate of delivery for the whole project. The article is great and I encourage you to read it.

From the article, I’ve reproduced the following graph, with one addition.

Mark calls out the design payoff line, below which you can achieve a faster delivery by taking on technical debt, but above which technical debt hurts in the long run. I want to point out how errors in estimation, or driving to deadlines, can hurt this process.

I’ve added two lines to this graph. There’s an estimated delivery time, and an actual one. If we are able to deliver the project on the estimated schedule, then it apparently makes sense to skip the in-depth design work, since the amount of cumulative features shipped is higher with the blue line than the red. However, in this example, if the actual delivery date slips, then you would have been better off investing in design. At the actual delivery time, the amount of features shipped by the red line is more than the blue.

The core rub here is that given any estimate of delivery, we should expect the mean value of the actual delivery to be later than that!¹ Delivery dates are dominated by their right tail. Consider that a project can never be delivered earlier than its start date, but it can be prolonged indefinitely.

This seems like an extreme claim, but my experience bears it out. If it were not true, we would expect to see at least half of all projects to be delivered earlier than their deadline. In fact it would need to be the overwhelming majority delivered ahead of schedule, to make up for the rare but extreme outliers that miss their estimates. In practice, however, work expands to fill the time available even in cases where the project is running well.

This means that an attempt to rationally decide whether a project can skip design and incurr tech debt based on an estimate has a systemic risk. This risk can blow up and hurt you in two ways. Not only is the project itself now delayed, but the entire codebase is worse off than if you had chosen a slower approach. If this project happened to be part of a larger coordinated schedule that is also time-constrained, well now your problems have only just begun.

I recommend that the next time you feel pressured to incur under-design tech debt because of a deadline or a low estimate, model out the scenario of what happens if the actual delivery time slips. If that scenario is unacceptable, it is worth your while to push back against incurring tech debt.

Remember, slow is smooth, and smooth is fast.

Have a comment? I’d love to hear your thoughts at this thread on Hacker News