Technical debt: A master class

Robert Lefkowitz offers a overview of technical debt, explaining how to prevent or reduce it, when to increase it, and how to use refactoring to refinance it.

Technical debt is a funny thing. While the term attempts to make an analogy with financial debt, technical debt and financial debt have nothing in common. Instead, it’s the name we give engineering decisions we disagree with. Robert Lefkowitz offers a overview of technical debt, explaining how to prevent or reduce it, when to increase it, and how to use refactoring to refinance it. Most so-called best practices today, are, in fact, technical debt (e.g., using a programming language that is “easier for the developer” (like Python) but which generates code that is slower for the user (when C++ would be faster). At the same time, the scale of an organization and the scale of a project alters the categorization of an engineering decision. In other words, whether a technology or technique is technical debt depends more on the size of the organization doing it than what specifically they are doing. Robert argues that technical debt is synonymous with good engineering practices. Robert then explains why microservices have been shown to be an anti-pattern, discussing the reasons why microservices are attractive, and how their implementation typically generates more technical debt than it pays down (i.e., microservice implementations are tech debt refinancing). The best solution for dealing with this new debt is to stick with immutable microservices and functional microservices—microservices that do not have any persisted data. Robert concludes by demonstrating how to reduce debt at the code level. Simply put, the fundamental maxim is “the less code the better.” And often, “less code” is also “less understandable code.” Robert explores the dynamics and trade-offs between these two and why “less understandable code” is the better answer.