Aging: Evolving Software, Tools, and Ourselves.
summary
Defines technical debt as anything that should change but hasn't and argues it accumulates both from internal hacks and external change, creating multiplicative network effects as downstream projects inherit costs. Recommends prioritizing compatibility over sweeping rewrites, citing the JVM’s long-term stability and Cats’ commitment to binary compatibility as effective defenses. Warns that migration tools like ScalaFix are helpful but unreliable in practice — migrating ScalaTest tests took about one-week migration in a real case.
AI-written summary · about
chapters (13)
- 0:00Introduction and speaker background
- 1:47What qualifies me to talk about tech debt
- 2:51Technical debt defined and its impact
- 4:13Self-inflicted vs age-related tech debt
- 7:46Costs of keeping tech debt around
- 10:38Strategies for dealing with tech debt
- 13:45Challenges of rewriting systems
- 18:01Total cost of paying off tech debt
- 20:48Network effects of tech debt changes
- 23:20Compatibility and stability in evolution
- 25:09Migration tools and their limits
- 26:55Case study: ScalaTest migration
- 29:03Key takeaways and conclusion
related talks
32mMaking Sotware Better, Despite Having Users
28mTechnical Debt: Why it'll ruin your software
32mMaking software better despite having users
26mTech debt as innovation, reframing this forever problem as an opportunity
35mTechnical Debt. A guide for developers and IT managers
52mTechnical Neglect
53mRewrite or Not? Life with Technical Debt
01h 03mLong-lived software architectures that survive decades without debt