Technical debt: A master class
Who is this presentation for?
- Software architects, engineering managers, and principal engineers
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.
- General knowledge of software engineering and software architecture
What you'll learn
- Learn how to avoid creating technical debt, how to reduce previously accumulated technical debt, and how to measure technical debt
Robert (r0ml) Lefkowitz is a frequent speaker on the intersection of software and literacy. Previously, he was a CTO at a fintech startup and held senior technology positions in the telecommunications and financial industries. He’s a distinguished engineer of the ACM.
Comments on this page are now closed.
For conference registration information and customer service
For more information on community discounts and trade opportunities with O’Reilly conferences
Become a sponsor
For information on exhibiting or sponsoring a conference
For media/analyst press inquires
No slides? :-(