Technical debt is a problem for most IT divisions that have been running for a while. The drive for quick delivery to market forces projects to run as fast as possible in order to meet business expectations – and unless a company is very disciplined from the start- this can sometimes come at a cost of shortcuts or ‘acceptable’ defects being introduced.
On a project by project basis this probably isn’t a huge problem – so long as you are within risk tolerance, some projects can go live with known defects or workarounds – but when you start thinking that a lot of major enterprises will be running hundreds of potential projects in a year, and some applications may be several years old, you could see how this could add up if a strategy isn’t in place to handle it.
One of the sanest ways to combat this is to move to a methodology that bakes quality into the process; agile methodologies are very keen on this. However for those companies that are transitioning to agile methodologies this means they could be facing a mountain of technical debt before they even start.
Where do you even start with something like that?
I read a very entertaining blog by Jergen Moons which makes some solid suggestions about tangible ways to approach handling technical code debt. The biggest take away I got from it is to start small and make consolidated targeted improvements as part of a long term vision that works alongside future development. I recommend having a look.