There are many companies consulting about Agile Development, and there’s a long standing movement spearheaded by the OMG supporting it. It’s gone well past the early adopters stage and become pretty much mainstream, replacing the bad old days of waterfall development, to the point where I don’t actually know of any software shops that don’t claim to be doing some sort of Agile. The underlying thesis is that software requirements change quickly and are hard to define precisely in advance. This was a response to the bad old days of 5-10 year development projects that were irrelevant by the time they were delivered, if they were delivered at all. Agile development is an old idea that was being talked about in the eighties when I started my development career.
Test automation came along much later, with more mature software engineering tools and testing frameworks. I started with a text editor, a command line compiler and actual stack overflows long before Stack Overflow was the website you went to for all your problems. Long before there were any websites outside the military. I’d say it’s only in the first follower stage, as there are a lot of companies I know who are only just getting started with it. They know they need it but they don’t entirely understand why or how to best use it.
There are now many companies consulting about Automated Testing, Test Driven Development, and Behaviour Driven Development, and many test automation tools vendors popping up on the market, named after various vegetables (and reminding me somewhat of the earlier fad where computers were named after fruit – Anyone else remember the Apricot?) and there’s a movement in the industry about Automated Testing now. There isn’t quite as much take up of it by the laggards and luddites on the innovation distribution curve, although some of the early adopters have had good results, but it’s starting to ramp up now, as we can see by the number of testing jobs that require automation experience.
So why is pretty much nobody talking about Technical Debt? It is another old idea that was being talked about back in the 1980’s, and is still relevant today, but nobody talks about it outside development departments.
But, technical debt is the dirty secret in the software development world. Nobody likes to admit they have any, and yet if you develop software that’s mature enough to be live on at least one customer site, I can pretty much guarantee that you have some. But I kind of get the feeling that nobody outside the Development team really even believes in it. It’s the invisible elephant in the room.
And yet, technical debt costs the industry trillions every year in wasted resources according to research published by CISQ, and furthermore it’s a major cause of dissatisfaction in the workplace at software companies – and not just for the developers!
“Technical debt costs the industry trillions every year in wasted resources according to research published by CISQ, and furthermore it’s a major cause of dissatisfaction in the workplace at software companies”
Yet there isn’t even an accepted and recognised way to measure it. Most software companies do not have a strategy to manage it according to CISQ. And this could account for why it is generally not being addressed.
It gets brushed under the carpet and ignored, slowly accumulating until your software becomes so unmaintainable that your company is forced out of business due to inefficiency or one too many catastrophic failures, or into a major rewrite project.
It’s not “just bugs”. Although high technical debt correlates with high bug numbers.
It’s not “just bad coding” although if you don’t have good coding standards, or any coding standards, you will probably have a lot of technical debt.
Technical debt means higher levels of bugs in production software. Repeatedly tested.
Technical debt means it takes longer to develop and test high quality changes, making it increasingly more expensive to add new features to your software. Also repeatedly tested.
And Technical debt gets progressively worse as your software grows if you don’t have a strategy for managing it. Pretty bleeding obvious right?
Then why is nobody talking about technical debt? Why are most software companies not managing it, and just soaking up the additional costs year after year?
So what are the symptoms that can alert us to the presence of technical debt in our software. These symptoms are quite common and you may well recognise some of them, but often the real root cause is not understood, and the problems are blamed, for example, on poor skills in the development team, or not enough testing.
But the problems are too widespread for that to be true everywhere.
Although Technical Debt can seem invisible, the symptoms become progressively worse over time, and these are all too visible to everyone concerned, even if their root cause is not clear.
Let’s have a look at some of these symptoms and see if you recognise any of them from your own workplace or previous workplaces.
Have you noticed new features are taking longer and longer to develop than they used to. Do Old timers in the company complain that changes used to happen much faster. Often they will blame the current developers.
Perhaps you’ve noticed Estimates for new features are getting bigger and bigger, and yet are still being missed. Developers and testers are unable to provide predictable estimates for changes.
Maybe Changes are resulting in unexpected bugs in different parts of the system. Often you will hear testers complaining that whenever a developer changes something, another unrelated part of the system breaks.
Are increasing numbers of bugs are being reported by customers in production following upgrades to new releases
Do the same bugs or similar bugs keep reappearing release after release?
Are Parts of your software hard to build automated tests for, and are your testers repeatedly spending time manually regression testing the same code, release after release, and worse, finding the same bugs?
Maybe Your software can’t be run on the latest operating system versions or software framework versions and perhaps you have to tell customers to stay on old versions, or perhaps you want to migrate to the cloud but your software was only written to use local domain authentication, or your customers want to run your application on mobile devices but your website was not designed responsively for small screens.
Are customers raising increasing numbers of security issues?
Do customers complain about software performance getting worse, or unexpected system crashes more and more often?
Is your developer turnover increasing?
How easy is it to recruit new developers with the skills you need?
Is developer morale low. Do developers complain about having to work on legacy code or using old technology?
Are there areas of the software that developers are afraid to touch and complain about having to work on, in case they break it?
The main sign that you have technical debt that you need to deal with, is that things are getting progressively worse as time goes on.