DEV Community

Discussion on: All Code Is Technical Debt

Collapse
 
antonfrattaroli profile image
Anton Frattaroli

Tech debt avoidance might be worthless at a micro level, but a lot of tech debt can be made cheap to remedy by choosing a adaptable architecture and avoiding framework lock-in. I think the article pigeon-holes the issue and ignores the greater scope.

Collapse
 
pbeekums profile image
Beekey Cheung

The counter to that statement is that architects learn new things too. There are always ways to improve on things from the macro level to the micro level. You'll probably find 10x more people talk about micro services than people who have actually implemented micro services at a large scale. That 90%, of which I am a part of, have a lot left to learn. And those in the 10% have probably thought of different ways of how to improve on what they've built.

Collapse
 
antonfrattaroli profile image
Anton Frattaroli

I've seen many devs who have fallen into a tech debt hole by getting swept up in a language or framework.

Take for example ASP.NET. Came out around 2002. First choice is VB.NET or C#. It didn't take an expert to read the community and choose C#. At the time, it only had the Web Forms front end framework, which is and was terrible. But when you stripped away the abstractions and focused on handlers/modules, you could have had up to 15 years before .NET Core comes along and you need to migrate to Web API. The migration is a trivial replacement of wrapper code.

Something a bit more difficult- 2003. You're presented with YUI, jQuery and MooTools that are each offering overlapping promises. It takes some hands on use of each, but experience would tell you the jQuery is your ticket. Could still be sticking with it today, although it has been less useful since browsers became more standard. Thankfully it isn't entirely monolithic, the UI library is separate and they have slim versions. Should a dev want to remove the dependency it is at least a step-down process.

Another one is javascript templating engines. A Mustache spec engine was/is the correct choice. ORMs another, but that depends on your stack.

Something more recent (I'll probably regret discussing) is the Angular/React/Vue/whatever else argument. Angular is like choosing ASP.NET Web Forms in 2002 and is a rewrite waiting to happen. React has its good and bad parts. The correct choice for cheap tech debt is to not use a framework and instead choose libraries wisely and implement with caution.