Technical debt is an interesting term we seem to hear a bit more lately.
I think anyone with experience in software development knows instinctively at least what it is. It's good that people are finally attaching a label to it. It's an important start.
Sometimes a team will seem to make incredible progress on early releases of some product, then may seem to slow down later. There can be a number of reasons for this slow down. One of them is productizing. Another is that with more users people will find more bugs and the team has to backtrack to address them, impeding progress on new features in the process.
But I think what often slows a team down later on is technical debt. In the early releases the team may have used unsound practices such as poor to no source documentation, poor to no unit testing, copy and paste code, heavily intertwined modules, death march project schedules. These shortcuts can yield seemingly rapid progress on a small team with a small code base over a small period of time.
However that progress comes at a price. Like an irresponsible man who lives beyond his means and uses credit cards to fund a flashy lifestyle. He seems prosperous to an outside observer but actually he's heading for a crash and what he has been doing is unsustainable. Technical debt is very similar to that type of financial debt. Much of the early progress is illusory, financed through technical debt. The result is an unmaintainable code structure that will require costly and time consuming maintenance and rewrites.
There are some hazards around technical debt, especially when a new team is asked to take over code originally developed by a different team. If the original team is too willing to part with the original code base then that may mean the code has a lot of technical debt which is coming due and the original team wants to put it on someone else to deal with it. Also with technical debt, if the later team seems to make less progress than the original team, that may be because the new team is being badly slowed by the burden of servicing the technical debt the original team ran up.
One good thing about technical debt now we have defined this "problem with no name" and put a name to it. From there it would be good if there was a way to take the next step and devise ways to measure the technical debt in a code base and in an automated way assign some debt level to the code and estimate the costs of servicing it. I think for some graduate students there may be some interesting and valuable original research that can be done in this area.
