Most adages have a converse. "Birds of a feather flock together," while, "Opposites attract."
Today we take issue with, "If it ain't broke, don't fix it."
The counter-intuitive approach is to break things all the time. I recommend this. Start breaking things or stay in bed until the sheets curl. But here's the trick--constantly break LITTLE things, and enjoy tractable, manageable surroundings. The alternative? Wait for great big things to break themselves. Wait for spontaneous nuclear concussions that level the landscape. Perhaps I should explain.
Passivity seduces. Leave well enough alone. In technology terms, if it's running, don't touch it. Don't patch it, reboot it, upgrade it, replace it. If it ain't broke, don't fix it.
But this sort of stability is an illusion. A router or server with an uptime of 713 days is not a steadfast pillar; it's a lit wick. 713 days? Did we forget about it? Do we not love it anymore? No patch or minor code revision for its birthday?
Windows XP and Internet Explorer 6 running fine? It may appear so, but that platform encumbrance incurs massive infrastructure debt. And sooner or later, the piper always demands his wages.
A January 27th TechRepublic article, "Avoid getting buried in technical debt," references debt as it applies to software development, a concept introduced by Ward Cunningham in 1992. We can consider "Infrastructure Debt" a useful abstract for emphasizing the cost of deferred action, whether it's a lack of documentation, rushed work, or sidestepped upgrades.
Too often we confuse stagnancy for stability. That apparent uptime costs plenty, and once we become cognizant of those costs, we'll realize that "a stitch in time saves nine."
Time to break something. We'll discuss the details in the coming days.
