Every software project I've ever worked on has accrued technical debt over time:
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2009/02/paying-down-your-technical-debt.html
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2009/02/paying-down-your-technical-debt.html
ra ra ra …
oh wait … it would have been more interesting to get insight into refactoring SO rather than just handwaving. What are some lessons learnt?
thx
So what architectural design ideas would help to minimize the accrual of technical debt? A modular, add future functionality like snapping on Lego blocks approach?
I feel the technical debt painfully and I will rewrite a large module of a survey site that I’m working on soon. However I will have to prepare a good speech for the project manager and other managers…
WIsh me luck.
I mean things like HTML response construction in code-behind by string concatenations and other coding horrors…
When I have unit tests, I don’t fear. I am pretty confident that if i broke something, I’ll discover it automatically. When I work with a system that does not have unit tests, I do fear. I’m afraid to make things better because I may have inadvertently broke something else.
These are the times when having a large battery of unit tests can be immensely useful. I’m just sayin’. 
I agree that sometimes it make sense to accumulate technical debt in order to meet some important deadline.
However debt accumulation shouldn’t last longer than couple of month. With time developers forget how code functions and what business logic that code implements.
It very hard to refactor old code, so repaying technical debt later in time is significantly more expensive than repaying it immediately after deadline is met.
I was always wary of fixing things back before I used source control. Now, I plow right in without thinking twice.
It took me years to realize how fundamentally and profoundly that one small change had unconsciously changed my behavior.
I’d also argue that accumulated technical debt becomes a major disincentive to work on a project
I have to totally agree with you on this one. I’m a Computer Science master student, and worked with 2 fellow students on a pretty big project in the Netherlands. We only had our university knowledge, and at that moment thought we made a very good (object oriented) MVC implementation that would surely be flexible enough for later changes.
After a year, and a lot of more experience for myself and my fellow students, the request for changes came. I had to look through all the code we had written to see where the changes should be made, and I was truly disgusted with our own code. To finish before our deadline we wrote a lot of code that was not very good, but it worked and everybody was happy. But now I had to make some changes I could not even find out for myself where to start. I got so frustrated about our own work that I eventually turned down the job, even when it paid a lot of money (for a student that is).
As a side note I have to add, that since that project, me and my fellow students have had a lot more experience (real world experience and not university experience) and that our latest projects are much better than that one. So one question remains: wtf have I paid my college tuition for 
Just tell Joel you’ll have the revenue generation going in six to eight weeks…
You reap what you sow. You have been planting crufty code and avoiding writing unit tests. You have even be bragging about doing it on your podcasts and everyone has been laughing at you.
Funny how it comes around and bites you in the ass a few months later!
Nice Dune quote.
Technical debt is an Abomination! I have spilled much water over deferments made early on in project.
I think version 1.0 of my programs is like a brute force attempt to get things to work, then 2.0 comes and it a little bit less brute force and a little more elegance.
You reap what you sow.
Unit testing, in this context, is irrelevant; you WILL make imperfect architectural decisions early on.
Technical debt accumulates on every project, because we have not yet managed to invent the mind reading, prescient programmer.
Now you could argue that having a lot of unit tests makes it easier to make sweeping architectural changes. That’s true. But I also suspect if your changes are deep enough, you’re going to break some tests, too – factor that time in as well.
But I also suspect if your changes are deep enough, you’re going to break some tests, too – factor that time in as well.
Right. It is better to let your users discover what you broke than to find out by tests going red, great point.
I love you, Jeff.
20
This is an interesting concept, Jeff. Going back to rewrite stuff due to architecture is usually a bad sign (doing it because of changing customer needs is different, or put another way, better understanding of customer needs). I find most of the time people have to go back and fix stuff is because of performance, and a lot of the time that’s because they used the wrong tools in an effort to deliver functionality faster.