The Deep Anchor and the Swift Current: On Two Kinds of Technical Debt
Technical debt is a weary phrase in our line of work, often spoken with a sigh that suggests a uniform, singular burden. We imagine it as a pile of rusty code in a forgotten corner, a monolithic obligation we’ll get to… someday. But I’ve come to believe this view is incomplete. There isn’t one kind of technical debt; there are at least two distinct species, each with its own ecology, its own dangers, and its own peculiar form of interest. In the small systems I tend to, I see them as the Deep Anchor and the Swift Current.
The Deep Anchor is the debt of legacy. It’s the Perl script from a previous maintainer, still running flawlessly but understood by no one alive. It’s the homegrown configuration management system built before Ansible was a glimmer in its creator’s eye. It lives in the foundations. It’s heavy, stable, and deeply embedded. The interest it accrues isn’t a constant drain; it’s the silent risk of the anchor snapping its chain during a storm. When you need to move the entire ship, the anchor, once a source of stability, becomes the single point of catastrophic failure. The work to pay it down is archaeological: meticulous, patient, and fraught with the danger of unearthing something fragile. You don’t fix the Anchor in an afternoon; you plan a careful migration, a slow and respectful decommissioning.
In stark contrast, the Swift Current is the debt of velocity. It’s the quick script you wrote to patch a leak, now handling a critical data flow. It’s the prototype feature, bolted onto the side of the main application, that somehow became core to a dozen users. This debt isn’t hidden in the foundations; it’s right on the surface, pulling you along. Its interest is a constant, nagging drag. It’s the extra minute of manual work every day, the slight instability that causes weekly pager alerts, the growing complexity that makes every new change just a little harder. The Swift Current doesn’t threaten a single, dramatic failure. Instead, it exhausts you, slowly eroding your capacity to steer. The energy you spend staying afloat in its flow is energy you can’t spend navigating toward your actual destination.
Tending to Two Different Gardens
Recognizing these as separate forces changes how I approach maintenance. The Deep Anchor requires a deliberate, project-based mindset. You schedule time for it, you gather resources, and you work with extreme care, knowing that a misstep could bring everything down. It’s a strategic operation. The Swift Current, however, demands a tactical, almost continuous response. It’s the work of refactoring that one function, adding a proper log message, or writing a unit test for the ‘temporary’ solution. It’s the maintenance you do between features, the constant, gentle push against the current’s pull.
The peril lies in confusing the two. Trying to yank up the Deep Anchor in a panic will capsize you. Conversely, ignoring the Swift Current, believing you’ll ‘deal with the debt later,’ ensures you’ll be too fatigued and too far downstream to ever reach the harbor where that foundational work can be done. The art of running a small, reliable service isn’t about being debt-free. It’s about knowing your creditors. It’s about understanding when you’re held fast by an anchor and when you’re merely being swept along by the current, and having the wisdom to apply the right kind of effort at the right time.
Notes & further reading
A few pages I came back to while writing this: