My Entire 20-Year Career Is Technical Debt or Legacy Code
This article has been translated from its original publication at https://apptractor.ru/info/articles/vsya-moya-20-letnyaya-karera-eto-tehnicheskiy-dolg-ili-ustarevshiy-kod.html
There is no such thing as perfection. Over time, what was perfect today will not be perfect in the future. Learn to live with imperfection.
Technical debt is the most popular term these days. People say, "We're rapidly advancing our MVP, minimizing technical debt!" They mention technical debt to appear cool or something like that.
I just laugh because, in the end, everything is technical debt.
If you don't believe that your entire career will also be technical debt, after reading this article, you will believe it. I will tell you how everything has changed over the course of my 20-year career.
First there was Basic…
My career as a developer started with Visual Basic 6. I created several different applications from 1999 to 2003. I think you can say that everything that was in Visual Basic 6 by today's standards is technical debt or has long been replaced. Long live "on error resume next!"
I spent a lot of time working with classic Active Server Pages (ASP) development. At one point, I was also an expert in making websites work with Internet Explorer 6 and Netscape Navigator. Now, that means very little on a resume!
Visual Basic, ASP, IE6, and Netscape are all long-forgotten technologies. As Strong Bad would say in those times, "delorted!"
Outdated languages: Perl, Delphi, Fortran, FoxPro, ColdFusion
There are many programming languages that have fallen out of use in the past 20-plus years, besides Visual Basic 6. If you built something in one of those languages, chances are people are trying to figure out how to rewrite it because it's hard to find programmers for these languages: Perl, Delphi, Fortran, FoxPro, ColdFusion.
Are there still applications written in these languages? Yes. Can you hire people for them? With difficulty. In most cases, companies have to modernize and retire old applications.
In the early 2000s, people thought Adobe ColdFusion was the hot thing. Do you remember its five minutes of fame?
Ruby on Rails is also at risk of being included in this list. It has fallen out of fashion, and finding developers for it is very difficult. What once made it unique is now available in other languages.
Programming languages come and go. Developers don't want to learn skills that are not in demand. It's always a balance of supply and demand! Developers quickly jump off ship and always want to have the "hot new thing" on their resume.
What happened to ActiveX, Java Applets, Flash, and Silverlight?
Some of the early applications I created used ActiveX controls in Internet Explorer 6. At that time, they were necessary for printing and other very insecure things. PDF files weren't as common back then, and printing from the browser was a nightmare.
Java Applets were also “a big thing” in their time. They were slow, and installing the correct version of Java on a computer was always a hassle. I will never forget the nightmare of dealing with network firewalls that required Java applets to be installed. I don't miss those nightmares, and fortunately, it's all in the past now.
We all remember Macromedia/Adobe Flash! At some point, it was the darling of the entire Internet. There were countless Flash games, and many applications were built on Flash using ActionScript. A product called CheerpX now allows running old Flash applications with WebAssembly.
Microsoft released a competitor to Flash called Silverlight. It was actually a pretty fantastic framework for C# developers. My company created some truly amazing things using Silverlight.
As we all know, Apple put an end to Flash and Silverlight by discontinuing support for them in their browsers.
Here's a screenshot of a financial calculator we created using Silverlight at VinSolutions over 10 years ago. Silverlight is no longer supported now, and they rewrote it in JavaScript, but it's not as cool as the old version!
My first mobile app
I created my first mobile app in 2004. It's hard to remember, but the iPhone and Android didn't exist back then. I developed an inventory application for car dealerships on a Compaq Pocket PC. It was written in C# for .NET Compact Framework to run on Windows CE.
That Pocket PC had a 1-megapixel camera. The photos always turned out terrible, although if it was cloudy outside, the glare would disappear. Oh, how technology has changed! That app has long been discarded, but in 2005, it was cutting-edge.
Better to be Swift
Swift is another great example of how development tools change rapidly. Once Apple released Swift, it became difficult to justify writing code in Objective-C. I'm sure there are some use cases where it's still necessary. But Swift is much easier to develop with and represents a significant evolutionary step forward.
I would argue that any apps written in Objective-C are most likely technical debt now.
WebForms
After dealing with crazy scripts to build web applications, I was thrilled to use the new ASP.NET WebForms. Their server-side controls greatly simplified development. Their goal was to make web application development as easy as in Visual Basic 6. And for the most part, they succeeded! You could create reusable server-side UI components to render in the browser, similar to what we do today with 100% JavaScript.
WebForms wasn't perfect, but it was a significant upgrade. It worked great until Ruby on Rails came along and popularized MVC (Model-View-Controller) frameworks for web application development.
MVC quickly rendered all our WebForms applications obsolete. Anything related to WebForms is definitely technical debt (although a similar concept returns with Blazor).
MVC: The King (for a while)
Before you knew it, every programming language supported MVC frameworks. We transitioned to doing everything new in ASP.NET MVC. It was everywhere, including Django, Laravel, Symfony, Spring, and so on.
Fast forward to today, and MVC is no longer in vogue. Everything is done with React, Angular, Vue, and other frameworks.
Before them, we had other JavaScript frameworks. At Stackify, we used Knockout, a fairly popular front-end framework.
Do you remember any of these frameworks? Knockout, Ember, Aurelia, Meteor, Backbone, Handlebars.
If you used any of them, I bet all that code is now considered technical debt and out of use. The first generation of frontend frameworks lost to React and Angular.
AngularJS
In 2015, Angular was created by Google and burst onto the scene. It quickly became the most popular frontend framework.
Then, in 2016, Angular went through a major update that was incompatible with previous versions.
Guess what that means? Everything from the initial version became technical debt. In my company, we have projects on the old version of Angular that are significant technical debt we need to update.
Good old SOAP and WCF
Before REST APIs and JSON became the de facto standard, another option was SOAP, which stands for Simple Object Access Protocol. It allowed for easy invocation of web services and automatic generation of proxy classes for service calls. It was primarily used in Windows Communication Framework (WCF) with XML.
It worked great... until it didn't. One of the worst projects in my career involved figuring out how to use security certificates between my company and another vendor through WCF and SOAP. The promises of SOAP and WCF were great, but it was a nightmare to maintain for a long time.
SOAP and WCF are two things I don't miss. Microsoft decided not to support WCF in .NET Core anymore. The preference now goes to things like REST, gRPC, and GraphQL. Although the community eventually created the CoreWCF project to keep it alive.
Over time, the types of technologies we used for invoking web services have changed. The old ways still work, but most people would probably prefer to retire them.
New language versions
Another common issue is the shift to major language versions, be it Ruby, PHP, .NET, or others. Usually, they require code changes or even rewriting.
When .NET Core was released, it was a new, lighter, and faster version of .NET designed to work on Linux. The core C# code translates fairly easily, but nobody uses just the core code for real applications.
However, in complex enterprise applications, there are many potential challenges when transitioning to a new version. It becomes a serious technical debt that needs to be addressed. Otherwise, you'll eventually get stuck on an outdated version.
Such major language version updates ultimately turn projects into a large graveyard of technical debt.
Stuck on an old external dependency
One of the biggest problems we encountered at Stackify was being stuck on an old version of Elasticsearch.
At some point, they made significant changes to its functionality that were not fully backward compatible. We were heavily invested in the old version, and all the improvement work turned into a massive technical debt and an upgrade project.
We kept kicking the can down the road, and eventually, we ended up far behind. This is another example of real projects burdened by technical debt that can afflict companies.
Open-source alternative made my code obsolete
At Stackify, we created our own tracing/profiling libraries for six programming languages. It was an incredible amount of work.
Now, OpenTelemetry has emerged and rendered all that work useless.
Why bother with our own development when you can use an open-source industry standard? Stackify is gradually working on phasing out the .NET profiler that I helped build.
Code deteriorates or becomes obsolete
Over time, you'll see almost everything you create being discarded and replaced for various reasons or based on outdated technology.
Several applications I developed early in my career were shut down because the companies were acquired and decided to use completely different technologies.
Most software has a limited lifespan that is shorter than you might think. Eventually, all code becomes technical debt that everyone wants to rewrite in a more modern way, or business needs change dramatically.
Of course, in the corporate world, there's a higher chance of having internal applications that seem to last forever. For example, a railroad or a major bank may use the same mainframe-based software for 40 years.
I predict that WebAssembly will eventually change today's frontend development, creating an entirely new world.
The true impact of technical debt
People always worry about minimizing technical debt when starting new projects. I understand that. There's a balance between getting things to work and making them perfect.
However, nothing becomes technical debt just because it's not perfect. There's no such thing as perfection. What is perfect today won't be perfect in the future. Learn to live with imperfection.
The other side of technical debt is how everything slowly decays over time. Either there are serious issues with upgrading to the latest versions, or the technology eventually becomes obsolete due to the emergence of new ways of doing things. Good luck finding people to maintain the old tech stack.
Ultimately, everything turns into technical debt, or projects get shelved. If you're lucky, your code will survive long enough to become technical debt for someone else.
Give it enough time, and all your code will be deleted.