Every software project accumulates technical debt. Like financial debt, it compounds over time if left unaddressed, making future changes increasingly difficult and expensive. But knowing where to begin tackling technical debt can be overwhelming. As our time is limited, we have to choose wisely. I got inspired after watching Adam Tornhill talk called Prioritizing Technical Debt as If Time & Money Matters. So before you continue reading this post, check out his great talk: Back? Ok, let’s first make sure that we agree on our definition of ‘technical debt’… Understanding Technical Debt Technical debt isn't just "bad code." It represents trade-offs made during development—shortcuts taken to meet deadlines, features implemented without complete understanding of requirements, or design decisions that made sense at the time but no longer fit current needs. Technical debt manifests in several ways: Code smells : Duplicated code, overly complex methods, an...
One of the mantra’s I always preached for my teams was the concept of 'Continuous Improvement'. The idea is simple and appealing: we constantly seek incremental enhancements to our processes, products, and services. This approach, popularized by Japanese manufacturing methodologies like Kaizen, promises steady progress through small, ongoing adjustments rather than dramatic overhauls. However while reading the ‘Leadership is language’ by L. David Marquet, I started to wonder; what if this widely accepted wisdom is fundamentally flawed? What if true improvement doesn't actually happen continuously at all? The stairway, not the ramp In his book, David explains that improvement doesn't occur as a smooth, uninterrupted climb upward. Rather, it happens in distinct, intentional batches - like climbing stairs instead of walking up a ramp. This is what he calls "discontinuous improvement," and understanding this concept can transform how your team operates. ...