What Technical Debt Is And How It’s Measured
There’s this saying that there’s more than one way to crack an egg. This concept applies to software engineering too. In engineering a software system, there’ll be more than one way to do it. This poses a challenge: finding the best way.
The Dilemma
It would seem that the best and most efficient ways of building software systems aren’t usually the most obvious and intuitive. A look at the computational complexities of brute-force algorithms [mostly intuitive, straightforward, obvious, and easy] vs their advanced but efficient counterparts [not so obvious and intuitive] should show this.
It’s easier and feels quite natural to reason about very simple solutions than advanced ones. Add to this the need to deliver features fast, and an engineering team may find itself choosing a quick and easy way over a time-taking, advanced, but better approach that would save everyone unnecessary maintenance costs in the future.
Team Decides: Let’s Move On People, We’ll Revisit This Later
To decide to go the inefficient, fast and easy way, a team may reason that at some future point, work will be done to cater for this “little” inefficiency: “We just need to move fast at the moment” becomes the mantra on everyone’s lips. It’s soon…
