Sell technical debt by avoiding the spider

How objective quality measurements keep software from spiraling out of control

Share this:

Every engineer and development manager knows – and every business owner should know – that technical debt is something that can and will ruin your business if you allow it to get too high. It’s like when the main Hobbit goes into that cave in that tedious Lord of the Rings movie. At some point, he gets stuck in the spider web and caught by the nasty spider. (If you haven’t seen the movie, you just need to know that somebody gets stuck in a spider web and nearly dies.) Of course, he gets saved by his friend, much like what happens in real life. You often face the same situation in software projects: the spider catches you, and you need to fight it off (well, not with Hobbits, that’s indeed a key difference).

But the movie is a little dull (for me, anyway), as it takes a long time before anything happens and ages to get anything done. If they could have walked easily through that cave, they would have missed the spider, and we would have saved at least five minutes. If only somebody would have cleaned the cave and taken care of the mess – the technical debt, in software terms. At some point, your software will become so complex that you’ll inevitably get caught by the spider.

Trouble is, everybody knows this, but there’s always that very important feature that needs to be built, that complaining client, that integration that needs immediate attention. So, how to strike the balance? How to avoid getting caught by the spider?

One easy way is to make things more transparent to all stakeholders. Make sure you know how messy your cave is; compare it to others and be sure you keep it as clean as you feel it needs to be. For this, you need an objective measurement. Just like some people would say the Hobbit’s cave was actually quite tidy (and others would only be satisfied with a marble floor hallway to walk through), you need an objective measurement. You need to benchmark yourself objectively against others. Then you need to determine for which key applications you want to be above par, outperforming the others. For some applications you just want to be on par and maybe for some others, you can accept being sub par. Just like the Hobbit only needed to clean certain caves thoroughly to make this film more bearable.

Let us help you sell technical debt internally by making things objective and making the cleaning of the cave a standard component of your development process. It can be done, we’ve got the tools and global benchmark to do just that. It really makes a difference.

Related resources