I met Julien Delange a few months ago. He runs a company called codiga.io It is a support tool to help developers write better code. It is a web-based tool that acts kind of like VI analyzer and will analyze your code and flag problems and make suggestions. It also has some IDE integrations. Julien is also responsible for snipt.dev, which is a code generation tool. You tell it what you want to do (something like read a text file line by line in Python) and it generates some example code that you can then copy and paste and then adapt to your particular problem. Unfortunately, both of those tools only work on text-based languages.

Julien is also into trail running. Lately, we’ve been trail running together and having some very interesting conversations about software development. He has a ton of experience and so I’ve learned a lot from our talks. We share a similar philosophy around software development, so when I learned that he had co-authored a book on technical debt, I had to read it.

Main Takeaways

Here are just a few of my takeaways from the book:

• Technical Debt is more than just code. The book breaks down technical debt into 6 main categories:
  • Requirements
  • Design and Architecture
  • Implementation
  • Testing 
  • Documentation
  • Deployment
  • Social
• Debt is inevitable. Even if we make a perfect decision today, with the pace of change in technology, that decision is bound to cause us issues at some point in the future.
• Not all debt is bad. When evaluating whether debt is good or bad, we need to look at whether we are being intentional and the level of risk that we are introducing.
• The key to being successful is to identify and be aware of the debt that exists and have a plan to pay it back. What causes problems is unintentionally taking on debt and ignoring it (ie not having a plan to pay it back).

Chapter Layout

The majority of the book consists of a chapter covering each of the 7 types of technical debt. Each chapter has a similar format. It starts with identifying the type of debt, how it occurs, and its consequences. Then it talks about how to identify if that particular type of debt is present in your codebase. It has metrics to track and some simple litmus tests you can perform. Then each chapter talks about how to manage that particular type of debt. This consists of steps that you can take to mitigate the consequences and to pay back the debt. The last part of each chapter talks about how to avoid this particular type of debt in the future. 

What I liked

I liked the pragmatic approach of acknowledging that not all technical debt is bad. The book included some real-world examples and case studies, which helped to illustrate both the benefits and negative effects of debt. It was nice to see a balanced look at it and see what real practitioners experience.

Breaking down debt into the various categories was really useful. It’s more of a holistic approach to software development. I particularly liked that the book specifically calls out social debt. The book talks about organizational smells (similar to code smells) to help identify social debt. I found those really insightful. I think social debt is the most important type of technical debt. Social debt causes teams to accrue all of the other types of debt and makes it harder to repay that debt. 

As an 8th added category, the book had a chapter about technical debt in machine learning systems. There are some key differences between machine learning systems and normal applications. Those differences offer some unique opportunities for technical debt. I thought it was a very interesting chapter.

What I Didn’t Like

The book is way too academic and theoretical. I would have much preferred a more practical book. The case studies read like academic papers and lack practical, actionable advice. It makes sense that it is academic when you realize it was published by MIT press. It does make for rather hard reading. Typically a book this size takes me about 2 weeks to read. This one took me almost a month. The opening chapters went rather quickly, but after that things started to bog down.

I Need Help

If you are having trouble tackling technical debt in your organization, we can help. Use the button below to schedule a call.