Technical debt: A master class

Description

Technical debt is a funny thing—it’s the name we give engineering decisions we disagree with. The name is an effort to make an analogy with financial debt, but technical debt and financial debt have nothing in common.

Robert (r0ml) Lefkowitz dives into the characteristics of technical debt. He uses those characteristics to point out that most so-called best practices today, are, in fact, technical debt. Using a programming language that is easier for the developer (like Python) but that generates code that is slower for the user (C++ would be faster) is the classic definition of technical debt (providing worse software for the user to make it easier for the developer). You’ll see that the scale of the organization and the scale of the project will alter the categorization of an engineering decision (i.e., whether a technology or technique is technical debt depends more on the size of the organization doing it than of the “it” that they’re doing). Robert explains why the formulation “technical debt” is synonymous with “good engineering practice.”

Having defined the terms and contexts within which they change meaning, Robert details how to avoid or reduce technical debt (refactoring).

“Microservices” is a system-level refactoring technique that has been shown to be an anti-pattern. You’ll examine 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 solutions to dealing with this new debt are to stick with immutable microservices (they can’t be changed) and also to have “functional microservices”— microservices that don’t have any persisted data. And you’ll explore how these patterns work.

You’ll spend time on code-level refactorings—how to “reduce debt” at the code level. Simply enough, the fundamental maxim is “the less code the better.” And often, less code is also “less understandable code.” Robert leads you through the dynamic and trade-off between these two—and why “less understandable code” is the better answer.