Today, I finally had time to read the great article by Matt Watson titled “My 20 Year Career is Technical Debt or Deprecated”. I have to admit that this article made me a little bit sad because, in retrospective, the hours and hard work put into those projects I worked on for years and now they are gone.
I can relate to all the points made by the author because I have been there. I remember working with WebForms in Visual Studio.NET. He includes some languages that I used in the past, I even got a FoxPro certificate early in my career. Borland Delphi was one of the applications installed on my PC.
I believe that the tech world is not the same since Ajax became a buzzword. It made JavaScript the forefront of the software development world that later was a powerhouse with NodeJS. The community has pushed the boundaries of what can be done with JavaScript. But, with every push it has come with full replacement and full rewriting of applications.
In my opinion, it is easier to replace applications today. There are a lot of boilerplate code out there created with open-source projects that can help to create an app quickly. That didn’t happen in the past because everybody was reinventing the wheel locally in companies. Even within the companies, there were duplicated systems that met the needs of business silos.
Anything from 10 years ago is basically dead or rewritten. No matter how clean your code is, 10 years from today, it will be replaced. The Angular that we know today is not the AngularJS from 2013. Maybe your entire system will be replaced or rewritten in less than 5 years. The speed of adoption of new technologies is so fast in today’s world that tech books are dated sometimes even before release. A while back, I started to write a free eBook about front-end development as an appreciation to the community. But I cancelled the project because of the time it requires to do it and the number of changes required as the standards change. For instance, the Object.observer() was removed from the standards while I was planning the book. If released with no changes, then the book could become viral for the wrong reasons because I might be teaching “bad practices” or deprecated code.
None of the applications I worked on in the 2000s are alive. That is a good thing because it implies that companies have found better solutions to the problems. Nevertheless, memories and friendships are created when coding applications within a team. Looking back, those memories were great even if they included pizza during late nights and weekends to ship the software on time. Coding those applications helped create a bond within the team that has lasted work changes. I still keep in contact with my past coworkers (now friends) to this day.
It is better not to be attached to our code. The code is dated by the blink of an eye. I remember a post from the creator of PrototypeJS mentioning that you are not your code. He talks about how the PrototypeJS library was obsolete and how he felt when his work was criticized. It would be sane to understand that technologies change and our code will be obsolete. A more comfortable peace of mind is taking this into consideration knowing that our work will not survive. Of course, I am not talking shipping code with bugs. But we should not take personally the creation or maintenance of computer systems.
Even our brains had moved on. I was talking with one of my coworkers from 15 years ago and while discussing the applications we worked on, we realized that we could not remember that many projects. In fact, the ones that we remembered we could not recall the actual details but the tech used.
In the end, I have the same conclusion as the author. Everything that we create will become technical debt or removed from the phase of the earth. Maybe, just maybe, GitHub will be the graveyard.
