I’ve been pondering a new term I heard the other day. The term is “code debt.” I heard it while listening to Jason Fried in this podcast and I can’t stop thinking about it.
Code debt to me is very real. It’s the debt you have to keep paying back when you have software that needs to be maintained, upgraded, and generally supported over years. The more debt you have the more your life will be consumed by it. You could call it an obligation to support a product or solution.
It’s a fantastic concept and something I keep seeing. I’ve even experienced this myself. Where you take on a project and build a software solution and then you end up having to support and maintain it over the years.
Jason at 37signals uses this to explain why you should release a smaller, simpler product. Less code equals less future maintenance.
It really makes you think twice about getting into a new project. More and more these days I’m asking myself. What’s going to happen in 6 months when the client realizes that this is not enough. That they’re going to want to upgrade to the latest version, or have us write custom modules to do new things. Or when something breaks.
Curious if you’ve experienced this or thought about it?
10 responses to “Code Debt”
Great topic! I really enjoyed that podcast too. I guess I have a bit of a different spin on it. I’m an in-house designer for a large e-commerce business. I’m working for people that mostly don’t know much about what I do. I’m not creating software, but “code debt” seems to apply to web page development too.
The emphasis with new projects is always on “how fast can you get something out there?!” with the promise that we’ll have time to circle back later and clean it up, which never happens. What results is kludgy code that creates more work in the future for us that the managers aren’t aware of or don’t want us spending time on.
There’s really no reward for taking time to code something properly in the beginning in order to save yourself more work in the future. It makes for a very frustrating work environment. I use this analogy: imagine if your desk is really cluttered and disorganized but you were never allowed time to clean it up so that you could get some work done, you just keep piling folders and papers and burritos and coffee cups on top of it. That’s our code, ha ha!
Yes and Yes.
Funny, I’ve been stuck on the same idea, and the idea has been pouring through my head as I think about the basic functions of our cms…
A very useful podcast.
That’s one of the reasons I got out of freelance work. The client kept coming back for upgrades and maintenance. The problem was, I hadn’t clearly specified what was considered maintenance and what was part of the original contract. So I guess you could say that I blindly walked into code debt without even knowing it!
Thanks for the great feedback everyone. The podcast just made me want to go out and create something and do it well.
Chris,
nice post. I’ve followed Jason’s blog for about a year now, i use Backpack and I’ve heard this podcast before. Code debt is a very real concept- he’s spot on with his comparison to the concept of inertia in physics and the difficulty of changing direction when there is greater mass. While a bloated feature-set undoubtedly makes for more mass and consequently trickier maintenance, I would argue that a bigger predictor is the way in which the app is architected. I’ve seen dense, feature-rich applications coded with good object-oriented principles that are a dream to maintain and extend and, conversely, I’ve seen seemingly-simple apps hacked together with no adherence to a framework or good design principles and they are a nightmare to work with and maintain. So while I think he has valid points and it’s important to whittle down the features to the core essential ones, equally if not more important is the need to develop the app with an eye towards good OO principles and code reuse.
sean
ps. i’m a fellow arizonan living in scottsdale, cheers.
Hi Sean: A fellow Scottsdale resident! Wow, so how did you find BrainFuel?
Thanks for the feedback. I think you provide a great point… that a very well written application can be a blessing to update and maintain. It all comes down to who developed it and the great mystery… did they do a good job. Thanks for writing.
We should do a BrainFuel get together some night with all of the Arizona people. Maybe bowling or something.
Chris,
my buddy Jamon told me about your blog. I’ve followed Kathy Sierra’s (another fellow 9rules member) regularly and when I saw you were on 9rules, I figured it was worth a read.
yea, let’s definitely meet up sometime. i’ll drop you a line next grid7 meeting we have (grid7.biz) and do the same if you put together a bowling event or whatever.
good to meet you
Sean
Sean,
Very cool. Yeah, Grid7 sounds cool. Also you should check out RefreshPhoenix… there was a link to it in my post from Saturday night.
Chris
[…] There was considerable discussion on how to plan Agile projects and deliverables with customers: in particular the issues of payment schedules for features (when to pay and how much); and how to address the code debt were of intrested me. […]
Nice! Here in Denmark there is a growing part of the programmers from the University with the idea that “Code?!?! That comes from India!”.. whereas I hold a B.Sc.E.E. and try and use my head when coding.
I have a rule which has worked so far: “Doubling the number of code lines will quadruple the chance of error”.
People ( most programmers I’ve met at least ) don’t use their head when coding – the use the rear end. E.g.: I used to work in a large, international company making Sound and Vibration Measurement systems. We did a new generation of systems and the guys who designed the data model LOVED themselves.. Sitting at a P4 2,4 GHz they made a HUGE, object oriented data model which took 10,000 code lines to set a single integer value?!?!? When running on a 398 MHz XScale this is not an option if it has to be “realtime”.. Finally, after 4 months of arguing with my boss 4 of us got to create a “Performance Improval Team”. 1 month later we had optimized the frame rate a factor x6, reduced the number of lines needed for setting the integer to only 100 ( including event handlers ) and the instrument actually worked now..
But complaining about managers’ decisions ( e.g. using .NET on the small platform or having Server guys design handheld software ) wasn’t a great leap for my carreer.. Good thing that Denmark needs engineers. Got another job and a 30% raise..
Too much time is wasted on bad programming, lousy design and bad communication / management. And also ignorant marketing. Will this change? I doubt it..