🐿️ Bypassing Technical Debt - The Insanely Profitable Tech Newsletter
Originally published 8th July 2024
There’s a stretch of road in my town that doesn’t make any sense. It’s not near any points of interest, there are no houses or shops there, and I rarely see many other vehicles using it. But it’s wide and fast, as if the builders expected lots of daily traffic. Checking the history, it looks like it was first a country road, then when demand for travel to Dover and the Continent skyrocketed after WWII, it was given a patriotic name and extended into a bypass to handle the load and keep drivers off local streets. But since then it’s been supplanted by a huge motorway, and now, except when that route is blocked, there’s not much reason for anyone to cruise down Churchill Avenue.
If you look closely, we’re surrounded by vestigiality: snakes have hind legs, your computer keyboard is designed to avoid typewriter jams, and Britain has an official door-knocker to prevent a recurrence of our 1642 civil war. Leftovers like these are evidence that our forebears were smart, but not precognitive: nobody would spell the word “knight” like that if designing English spelling from scratch, but Chaucer wrote it as he heard it, unaware of coming changes like the Great Vowel Shift. The odd relics we trip over made sense to those who created them, and per Chesterton, we should always ask why a fence is there before removing it.
This is why, as I’ve evaluated hundreds of tech organisations around the world, I’ve learnt tocringe when I hear about a “total rewrite”. It’s easier to write code than to read it, so engineers are always keen to create the “right” design, to clear away the strange workarounds and odd constructions of their predecessors. But binning your software and starting over is a classic mistake, known to be foolish since Netscape tried it last century. It’s healthy for developers to make incremental changes that address the “technical debt” they’ve inherited, so long as they don’t down tools entirely; there are excellent techniques with names like “Strangler Fig” that allow them to organise that improvement work while continuing to deliver frequent value to users. Any programmer who tells you “refactoring” the code will take months doesn’t understand what that term means, so send them to me for some re-education–and a reminder that the human body, surely at least as complex as your software, has somehow managed to muddle through despite its useless tailbone, superfluous appendix, and inconvenient wisdom teeth.
This first appeared in my weekly Insanely Profitable Tech Newsletter which is received as part of the Squirrel Squadron every Monday, and was originally posted on 8th July 2024. To get my provocative thoughts and tips direct to your inbox first, sign up here: https://squirrelsquadron.com/
