The timer flashes red 5:32, 5:31, 5:30 counting down to its final terrible conclusion. James Bond calmly leans over the device, “So is it the red or green wire, let’s go with lucky red”, snip. The counter jumps from 5:24 to 0:30. ”Ahh not so lucky red, lets try the green”, snip. The counter stops, 0:07 “humm my lucky number” says our hero.
And that’s the way it is in the movies; the hero disarms the bomb with 3 seconds to spare on the clock and is home in time for tea, while the world sleeps soundly in its bed.
But this is not the movies, the ticking time bomb of technical debt is ticking louder and louder, and the clock is counting down faster and faster, so where is James Bond when you need him? Well I will tell where he is, he’s been outsourced and the only contract out on James Bond these days is the one that says deliver to this date, at this price or else!!. He is too busy trying to keep his head above water to try and disarm the technical debt bomb; in fact he cannot even hear it ticking.
But lets be fair it’s not just the trend of outsourcing that has generated the technical debt crisis, technical debt started with the very first program 60 years ago, the first “I’ll fix that later”, the first “the design’s not great but it will do”, the first cry of “just get it out the door”.
So if the bomb has been ticking away for 60 years and we have been blissfully ignoring it for just as long why should we care now?
First, as my colleague Andy Kyte has stated, technical debt and its big brother IT Debt will break the trillion dollars mark in the next 5 years. That’s a trillion dollars of development that needs to be done to remove bad code, poor architecture, and ill thought out technical strategy or simply time catching up with good design.
Second, the pace of business and technical change, coupled with faster delivery methods like agile and citizen development are speeding up the timer. Agile is a double edged sword, when done right practices like refactoring can help us remove technical debt and stop it being introduced in the first place, when done wrong agile can be a technical debt generating machine. The trend of agile outsourcing driven by the margins often ends with the outsourcer saying “refactoring looks like re-work and re-work is hard to bill for so we won’t do it”.
If you think this is analysts FUD or me being negative on agile, consider this. In 2011 I had over 400 calls, over 20 workshops and 50 plus face to face meetings at conferences all related to agile, and not one started with “Dave I am concerned about my technical debt”, not a single one. If pushed to give a figure I would say less than 30% of organizations using agile are really refactoring to the levels they should.
And what happens when your organizations technical debt bomb goes off? Well first it does not go off with a bang, it’s more a slow burn. Change starts to take longer, you cannot react to the needs of the business, mobile and cloud initiatives start to run into trouble, and opex costs start to spiral – it will not be a single cataclysmic event, it will be death by a thousand cuts.
What to do? Start by acknowledging that the ticking sound is not a server hard drive on the blink but a much larger problem. Don’t wait for James Bond to abseil into your data center and disarm your technical debt bomb, you’re going to have to do it yourself (abseiling optional). You need to get a handle on the size of your technical debt and take steps to make sure you’re not adding to it more than you have to. And then you can start to actively remove the debt and disarm the bomb.
Good luck Mr Bond tick tick tick…….
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.