Technical Debt

I was speaking with one of the development teams at Redgate earlier this year. They were working on a product, and had planned out a few sprints worth of work. Each sprint, called a train, was a couple weeks long, with specific goals and ideas to be implemented. That was all good, but I noticed that there was a sprint in the middle of the list that was devoted to technical debt.

Technical debt is a strange term. It’s one that many managers don’t understand well, often because the code may work fine. I ran across an interesting piece that looks at what the concept means, with what I think is a good explanation. We get technical debt when we sacrifice maintainability to meet another requirement. The piece also looks at the accumulation of the debt and why it becomes problematic later. Certainly the more debt that piles up, the mode difficult it can be to change code. Since we are almost always going to go back and maintain code, this becomes a problem.

I think the ideas given to keep technical debt under control are good ones. We should make an effort to clean code as we can, though not make it such a priority that we end up causing more work with constant refactoring. We do need to get work done. However the suggestions given require a good amount of discipline and buy in from management, and I’m glad Redgate tries to keep debt under control. I think our developers like the debt trains as well.

I thought the idea was pretty cool until I was looking for a feature to be completed and the technical debt train was running that week. I thought about complaining, but I decided to have patience and wait a week. After all, if the debt isn’t kept under control, I might be waiting much longer than a week for some fix or feature next year.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 2.4MB) podcast or subscribe to the feed at iTunes and LibSyn.

About way0utwest

Editor, SQLServerCentral
This entry was posted in Editorial and tagged . Bookmark the permalink.

4 Responses to Technical Debt

  1. Annette Allen says:

    I think it’s good that Tech Debt is factored in. I worked in an agile environment where our tech debt pile just kept growing because features were more important and we very rarely got to looking and fixing the tech debt.


  2. I think some of the worst technical debt usually comes in the form of security. The kind where “to make it easy” all accounts are given sysadmin, or worse still, domain admin so that permissions aren’t “a problem”. Then, further down the line, trying to correct that and apply the principle of least permission to the account becomes a nightmare of trawling through things like file shares (which are being accessed through XP_cmdshell…) just to ensure that the key business function they now service can continue to function.

    I’d happily wait a long while for new features to see problems like that get sorted!


  3. way0utwest says:

    That’s a great point. Security is certainly a place we try to avoid fixing when it’s poorly implemented.


Comments are closed.