David Gammel asked the following in the comments on my previous post on technical debt:
Do you think the technical debt has to be paid off with a balloon payment? It seems to me like you can’t really pay off this kind of debt on a 30-year fixed interest model, it all comes due at some point in the future and must be paid in full, at once, in order to move beyond it.
Or can you refactor code consistently and in essence pay it off with small payments over time?
I think it very much depends on the form of debt. As a matter of habit, whenever I work on code in an application that seems difficult to understand or badly written, I take the time to try to improve it where possible. I think that constant weeding and pruning are the key to maintaining a nice code base, and nobody seems to know or mind when what would have been a one hour fix turns into a two hour fix because you went ahead and made things a little better while you were in that code anyway.
On the other side, there are cases where technical debt has to be paid off all at once. For example, one application I work on is still running on Rails 1.1.6. Rails is now at version 2.3, and there have been a multitude of changes that would make this application easier to work on. Unfortunately, migrating up to the latest version of Rails is going to take a fairly substantial chunk of time, and it all has to be invested at once.
In both of these examples, good unit tests are the key to being able to pay off the debt at all. In the first case, making “improvements” to the code while you’re working on it can be risky if you don’t have the tests you need to insure that you haven’t broken the business logic in an effort to clean things up. In the second example, having a solid suite of automated tests makes it possible to rapidly locate and repair all of the problems you run into when making a large set of changes.
I suppose then that I’d argue that inadequate tests are one of the most painful types of technical debt that a project can accrue. On the upside, it can be paid off gradually.
Paying off technical debt
David Gammel asked the following in the comments on my previous post on technical debt:
I think it very much depends on the form of debt. As a matter of habit, whenever I work on code in an application that seems difficult to understand or badly written, I take the time to try to improve it where possible. I think that constant weeding and pruning are the key to maintaining a nice code base, and nobody seems to know or mind when what would have been a one hour fix turns into a two hour fix because you went ahead and made things a little better while you were in that code anyway.
On the other side, there are cases where technical debt has to be paid off all at once. For example, one application I work on is still running on Rails 1.1.6. Rails is now at version 2.3, and there have been a multitude of changes that would make this application easier to work on. Unfortunately, migrating up to the latest version of Rails is going to take a fairly substantial chunk of time, and it all has to be invested at once.
In both of these examples, good unit tests are the key to being able to pay off the debt at all. In the first case, making “improvements” to the code while you’re working on it can be risky if you don’t have the tests you need to insure that you haven’t broken the business logic in an effort to clean things up. In the second example, having a solid suite of automated tests makes it possible to rapidly locate and repair all of the problems you run into when making a large set of changes.
I suppose then that I’d argue that inadequate tests are one of the most painful types of technical debt that a project can accrue. On the upside, it can be paid off gradually.
Commentary
software developmenttechnical debt
Previous post
Involuntary gated communityNext post
Sell optimism