How Big Is Your Deficit?

by: Chris Barrett (VP Engineering)

No, this isn’t another commentary about sovereign debt or the government’s budget.  I’m referring to the technical deficit that accumulates when a product team rushing to deliver a development project is forced to make tough decisions like:

“Yes, we should develop this in an all-encompassing way.  But there’s no time to lose!  So let’s take a faster, more focused approach.  We’ll deal with the rest later.”

“We’ll put all those bug fixes into the next release.”

“We can live with that behavior for the time being.”

These are often the right choices at the time.  I’ve certainly seen companies delay a product launch too long while they polish every little bit of tarnish on every minor feature. In the meantime, a competitor releases a product that is “good enough” and eats their lunch.

Yet product executives should still be aware of the technical deficit and consciously decide whether they need do something about it. If you don’t actually know what your deficit is, I suggest you wander down the hall and talk to the engineers.

The list of technical compromises often gets pushed out of sight because rarely is anyone willing to pay to address it. Some items may get fixed when a customer demands it or when a piece of code happens to be rewritten. But over time, forgotten bugs start to trip up the development team. Gradually it ends up taking half an hour to compile software that used to compile in a fraction of the time. The engineering team can’t seem to churn out features as fast as they used to. In the lab, they start talking about how a “total rewrite” will soon be necessary to advance the product. There are hundreds, or even thousands, of bugs in the tracking system that haven’t been resolved for years. All this adds up to higher development costs that compound release after release unless you bite the bullet and start to work off your debt.

One solution is to make a good hard “bug scrub” one of the “features” in your next product release. Just take some percentage of your backlog and start cleaning things up. Or consider a “strengthen the business” feature.  Have someone work on improving compile time or creating tools that will save effort in the future. If you consider the potential recovery of lost development time these approaches will pay for themselves in short order.

Assuming some technical debt can make sense.  But eventually you need to face the music.  So be sure to pay some off from time to time before, like the Greek financial crisis, it spirals out of control.

  • Categories