Developers often try to minimize the amount of technical debt they take on when building software. Many will even try to have “zero” technical debt...
For further actions, you may consider blocking this person and/or reporting abuse
Nice post but I'm still uncertain what you meant by "When a developer learns a better way of doing things, it makes every line of code they have written in the past suboptimal"
Also, you seem to equate technical debt to suboptimal. Aren't those two things different?
Conceptually yes. Practically no. You start at a company and you see code that is making things harder than it should be. Do you try to differentiate between the two or do you just treat it as technical debt?
The point I'm making is: a developer writes some code. They learn to make that code better later on, but don't have time to rewrite it. If they went back to that code it would start to look painful because they know how to make it better. By default now they have technical debt because if they left it alone and tried to build on top of it, it would be off of a technical solution they know to be inferior.
Thanks for expending on that.
Typically code reviews eliminate most of these technical debt you described. I tend to think of technical debt as a "team debt" due to specific constraints such as time or resource.
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.
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.
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.
Think you hit the nail on the head with that sentence. The more I learn, the more I find that I have to learn even more to improve the code I've previously written.
Here Kevin Scott LinkedIn V.P of Eng. definition of technical debt:
"The reason that we call these compromises and mistakes technical debt is that in a very real sense you are borrowing against your future to get something done in the moment that you will pay for later, one way or the other"
he is taking about companies but it can be applied to individuals also.