Technical debt: A master class





Who is this presentation for?
- Software architects, engineering managers, and principal engineers
Level
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.
Prerequisite knowledge
- 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

r0ml Lefkowitz
Retired
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.
Platinum Sponsor
Gold Sponsors
Silver Sponsors
Exhibitor
Innovators
Supporting
Community Partner
Contact us
confreg@oreilly.com
For conference registration information and customer service
partners@oreilly.com
For more information on community discounts and trade opportunities with O’Reilly conferences
Become a sponsor
For information on exhibiting or sponsoring a conference
pr@oreilly.com
For media/analyst press inquires
Comments
Any slides?
No slides? :-(