If you want to address tech debt, quantify it first

🔗 If you want to address tech debt, quantify it first
stackoverflow.blog

When Ward Cunningham coined the technical debt metaphor, he needed a way to discuss the decisions made early in a project that were coming back to haunt his engineers as they continued building down the line. He was at a firm doing financial software, so a fiscal metaphor was in order. The technical decisions they made early on for the sake of getting a product to market might not have been the decisions they needed now, and unless they fixed them, the team's productivity would suffer and features would be slower to release.

This metaphor has caught on and become so prevalent as to barely need explaining. Plenty of successful companies used tech debt to get off the ground, only to pay it off later. For example, Facebook was originally written in PHP. The first implementation worked for what it was, but as they added features, complexity, and scale, they needed to pay off the significant debt that was PHP. It's worth noting that tech debt doesn't necessarily mean your original choice was flawed. Writing the site in PHP wasn't a bad decision at the beginning—this wasn't a case of bad code biting them later. It was a fine language that they outgrew.

In fact,the thing holding back anyone trying to upgrade from an outdated framework or library isn't a technical issue. Like the metaphor, the main hurdle is financial. I've seen plenty of upgrades put off for years because of the burden required to install, convert code, and test the effects of the upgrade. Meanwhile, the unpatched security holes could be leaving you vulnerable, and the new features you're not getting could leave your application at a disadvantage in the market. Someday, though, that bill will come due.

Obviously, tech debt is more than language and tool updates. It can be good-faith coding decisions done for an immediate benefit. The sooner you can address your debts, the better. But addressing those debts requires you further dig into the tech debt metaphor and quantify exactly how much debt your engineering team is carrying.

continue reading on stackoverflow.blog

⚠️ This post links to an external website. ⚠️