Cost of delay and opportunity cost when you don’t build quality in

Let’s talk about cost of delay – the cost of having NOT done something. Basically the opportunity cost of choosing to do one thing over another. Seems simple enough but it’s not.

Story time: company decides to be a feature factory and output new features like mad. Customers want more so they deliver more. And more. And more.

Short conversations are had – “We need to hack this together to get it out the door.” “We will fix it later.” I’m sure no one has had those conversations before (sarcastic AF).

And we incur loads of technical debt. That we continue to push off. Until…our feature factory slows down. Any change made breaks other areas. The code is brittle. It won’t scale to the performance levels we want it to because those hacks weren’t intended to support it. Sure, it’s great that our features are successful and need to scale, but now we’re paralyzed by technical debt. How could we have done it differently?

Not to say what was done above was incorrect or never happens – it does. We work work work to get something out by a client deadline, a large conference, a point in time in the year (e.g. holiday week) and we knowingly keep paying on credit. But the interest is coming and it looks like this:

What we need to do is assess up front what the cost of delay is for not writing the code correctly the first time OR for doing another net new feature over paying down the debt we’re rapidly incurring.

Is the value (urgency, risk reduction, opportunity enablement, revenue generation or cost reduction) in doing this net new feature more or less than doing this technical debt (or maybe other net new feature). Sure, we should be doing this in our prioritization of backlogs in one way or another. BUT are we also asking that if we need to do this other thing later, how does that value (above criteria) compare with doing it then? Let’s incorporate the opportunity cost of waiting and think about a few other items when comparing the value of the two (or many items) relatively:

• loss context of the problem(s) in the code and code familiarity
• brittle code that could break other things (RISK)
• engineering time to fix something later down the line (in addition to the above reasons) and the greater amount of time it will take to fix
• applying this cost of delay to a more important or valuable net new feature (or other work item) we don’t know about yet but not being able to do it because of the opportunity cost we pushed off

So what do we do about it? Well first, let’s have these discussions. It doesn’t mean you can’t make decisions to push off technical debt or new features for that matter. It’s just going into it as eyes wide open as possible; also knowing that when we estimate anything we’re very often wrong.

It’s bringing the discussion of technical debt more into the forefront of your prioritization. It’s adding those items to your backlog, release plan, and roadmap. It’s making it the rule, not the exception. It’s leaving the code a little better when you leave it than when you found it. It’s getting to a point where we have less large pieces of technical debt and instead smaller items that we work on each sprint. Fixing it becomes habit instead of one big bang release per year (which in my experience doesn’t work very well but it’s still better than nothing).

Make it a regular part of the conversation. Record themes and track patterns of where the main defects in your code are coming from. Make refactoring great again (sorry I couldn’t help it!). Oh and testing – do it! Automated unit and regression tests on as much as possible – put it in the definition of done and adhere to that shit!

The main rule to adhere to here is: it will always cost more to fix later. Remember that if nothing else.