Understanding and Eliminating Technical Debt

I'm pleased to announce that my fourth Pluralsight course has just been released, on the subject of "Understanding and Eliminating Technical Debt". If you've been following this blog for any length of time you'll know that Technical Debt is a topic I care deeply about. In fact, in many ways, it has become one of the main focuses of my career as I am technical lead for the ongoing development of a very large and successful software project that has over one million lines of code. In fact, it is typically successful software projects that have the biggest issues with technical debt, because as a general rule, technical debt is proportional to the amount of code you have.

In the course I attempt to give a big picture overview of what problems technical debt can cause, how you can identify it, and how you can go about repaying some of it. I take quite a broad definition of technical debt, encompassing any decisions we make (whether intentionally or not) about the way we write our code that slow down future development. I know this isn't how Ward Cunningham originally used the term, but it seems that the industry has taken his metaphor and applied it more broadly. (For example, see Martin Fowler's "Technical Debt Quadrant").

In the course I ended making up some of my own terms to help me express the breadth of issues that could fall under the category of "technical debt". These were:

• "code debt" - issues with the way we write our code (such as failure to write clean code) are slowing us down
• "architectural debt" - shortcomings in the architecture of our software that make it hard to extend in the direction we need to
• "test debt" - slows us down because we can't quickly verify everything is working correctly
• "knowledge debt" - where developers don't fully understand the system they are working on
• "technological debt" - where we've got stuck on a legacy technology and the cost of migrating away is too great

In the course I don't assume you're using agile process, or TDD, or indeed up to date technologies or best architectural patterns. And that's because the simple fact is that there are lots of software projects out there that are being actively maintained, but that have not been built using what are now considered to be "best practices" for process, architecture or coding techniques.

One of the biggest challenges creating this course for me is that every company is different. When I talk about technical debt where I work it's easy for me to make it very relevant because I know what the specific issues we are facing as a team. But on Pluralsight, I'm speaking to a worldwide audience of developers working on all kinds of systems. I've done my best to keep the content as broadly applicable as possible. But please do give me feedback, and tell me about the technical debt issues you're facing, and what you've done to deal with them.