Weeks ago, the county repaved one of the roads we use on a daily basis. They positioned signs at either end of the road warning drivers that there was loose gravel — super helpful at the beginning for those who wanted to slow down or avoid the road altogether.
The signs, however, remain there after weeks of traffic and a wave of storms that had long cleared the loose gravel. For local drivers, the signs no longer hold meaning (except maybe to elicit a snicker that they still have not been collected).
Alternatively, the signs may pose their own hazard for drivers less familiar with the area. If an out-of-town driver were to slow for fear of gravel, a local driver could become enraged or cause an accident because they didn't expect anyone to drive slowly on that road.
As silly as it seems, I used the stale signs to explain to my kids why it's important to "run our fences" and manage tech debt. While I pass no judgment on the county (a level of logistics that even my five-kid household cannot rival), leaving the signs out beyond their useful value is much like the loose ends we often abandon within our systems:
Best practice says that we need to define an appropriate length of time to warn drivers of the risk of gravel and then systematically collect the signs once they are no longer needed. Why?
In the same sense, we often abandon loose threads within our software code or leave stale data out in the ether because it is easier just to move on. We can comment out code or provision more server space much faster than we can perform the appropriate due diligence.
Without proper foresight, we leave ghosts in the machine for others to find and later manage. The next generation of product owners and development teams are at the mercy of our castoffs when they try to reverse engineer the function or determine the useful life of stagnant data.
We do ourselves and our successors a favor when we keep things crisp, such as removing and regression-testing dead code blocks or dropping datasets beyond their useful life.
These are obviously very high-level examples. And while I realize that volumes have been written about tech hygiene in a more straightforward sense, the novelty of the stale road sign is a powerful analogy to remind ourselves of this principle — not only in tech debt but throughout our daily lives.
The left-behind street sign as a nuisance and example of poor stewardship turned dangerous in a severe storm. Immediately after I took this picture, another driver came flying around that corner and slammed on the brakes to avoid hitting either my car or the downed sign. Thankfully, I'd stopped well back from the stop sign, and they skidded into the empty lane in front of me.
Not only was the sign left long after its useful life, it was not properly weighted for the storm conditions. This happens when we don't "run our fences" and address the clutter that starts to collect from the passage of time and the evolution of approach.
Technical debt creates clutter and introduces opportunities for chaos.
By tending to the hygiene of our environments, we pay it forward to ourselves and/or the users and architects that will come after all of the tribal knowledge has left. If nothing else, be vain and do it so you don't look silly. I don't have pictures to prove it, but I flipped the loose gravel sign over so it wasn't lying across the road.
The storm's wind caught it where it landed on its side point — looking like someone had fallen over in a jumping jack position. (No, I would not wade through the muddy ditch in the torrential rain to make further adjustments.)
It looked foolish in that position for another week until someone mercifully collected it. If you see me with a little smile as I turn that corner each morning, now you know why.
