In the previous chapter we’ve explored the consequences of components or systems going into a Legacy state. We’ve seen that it changes into that state due to external events which are beyond our control. This time we’d be diving into the main cause for these external events. Luckily it is probably the only thing that we can all agree on. Time moves forward. Unfortunately, technology moves forward as well. Time and technological advancements are the main cause of Legacy.
A Disturbance in the Force
This old meme from 2019 came to mind as I was writing this:
Panic. That was what foldable phones did to frontend/web/mobile developers from all around the world. It hit product managers and designers as well. Compatibility is one of the most annoying challenges an engineer needs to handle. Adjusting to foldable phones is compatibility on steroids. It requires adjusting to an entirely new concept, a whole lot of rendering.
We’d now have to imagine how it was when the entire concept of rendering has been reinvented. And then again. And then again!
The transition from Server Side Rendering (SSR for shorts) to Client Side Rendering (CSR) was short in a time span compared to other transitions. It was a matter of only a few years until we ended with a somewhat stable state of the modern web frameworks (Angular, Vue.JS and React). As much as I’d love to get into the fascinating details of all the iterations we went through, we’d better focus on the causes and effects of the iterations themselves. And waste.
An internal catalyst of an engineer to adopt new technologies could be of innovation and ease of development. The external catalyst is hunger. CSR has made the web faster and prettier, meaning satisfied customers and users. This immediately translated into better business results and even higher customer expectations. And if you couldn’t keep, you’d fall behind. It wouldn’t be just your database falling behind, it would be your business itself. A small taste of it would be the rivalry story of two insurance companies in Israel who were eWave’s customers.
One company has decided to entirely change their customer’s experience, to show them that even something as stale as insurance can be innovative. That was the branding of it, led not by R&D but by marketing. It came down to a competition between the latest in enterprise technologies, IBM’s WebSphere and Microsoft’s Sharepoint 2016. The winner would get a 50m$ project that would include replacing the entire company’s infrastructure. After a very successful PoC, Microsoft had won because they were able to provide a superior search based experience with an amazing user interface.
SharePoint 2016 was able to facilitate gorgeous and fast websites as it already natively supported Web Services with JSONs and a somewhat mature CSR capability. If the company would wish one day to replace the entire platform, Microsoft has made sure it wouldn’t be hard to migrate to SharePoint 365, their latest PaaS platform. If the company would wish only to replace the frontend to an even newer experience with an ever newer technology (React.JS for example) they would not have to replace the platform/backend at all. This flexibility in replacing components and technologies is what’s preventing a company from being hermetically closed to change. Replacing only a single component at a time instead of an entire system at once is what allows you to keep up with technology.
On the contrary, the other insurance company was still running a 7 years old enterprise technology and they were tightly coupled to it. It supported only SSR (tons of server code) and required a huge effort just to publish a SOAP/WSDL endpoint that responded with XMLs only. No support for any modern client technology. Their marketing department was hungry too. As they were locked out of replacing the platform, they had to keep up in some form. In order to do so, they had to mish-mash a lot of old technologies, come up with solutions for problems already resolved by newly released technologies. That is waste, inefficiency and a Velocity drop. No wonder they never caught up.
Faster, Stronger
It is not a situation inherent to enterprises. They might be experiencing it more as enterprises do react slowly to technological advances. But even startups, who supposedly react faster, could have trouble keeping up as sometimes the pace of external events is too fast to follow.
Such could be the case of trying to keep up with Angular.JS. Let’s have a look at its release timeline and frequency.
| Version | Date of release | Time passed since last |
| V1.0 (a.k.a AngularJS) | October 2010 | |
| V2.0 (a complete rewrite) | October 2014 | 4 years |
| V4.0 (V3 was skipped) | December 2016 | 2 years |
| V5.0 | November 2017 | < 1 year |
| V6.0 | May 2018 | ~ six months |
In mid-2015 our fictional young and upcoming startup decided to go with the latest and somewhat mature Angular.JS version 2.0. Within only a year and a half the startup would find itself with obsolete technology. No one could have anticipated that version 4.0 would not be backward compatible at all. All of our engineer’s experience with v2.0 had gone down the drain as well. And v4.0 has quite the learning curve. Obviously it happened at the worst time possible [see Second Year Syndrome]. On the one hand, rewriting the entire client would be too time consuming and on the other hand features and business goals need to be met. Nothing left to do but to continue working with the Legacy version and continue the development of our client. Everytime we’d need to fix an already resolved issue, we’d be creating waste. Not being able to keep up with the latest technology causes waste and is a cause of inefficiency.
A release of a major version always has the potential to include a breaking change. Angular.JS release timeline demonstrates how time spans between releases is getting shorter and shorter. Node.JS’s major release interval is of six months. We are not the only ones working in Agile. The teams that code the packages, frameworks and technologies we use work in Agile as well. Not only that technology progresses, it progresses faster than ever. We would end up with legacy technologies sooner than we would ever expect.
The Wrong Bet
It’s out of control that technologies come and go. Thus we would eventually bet on the wrong one. Let’s examine the case of Ruby on Rails. Back in 2010-2012 RoR was in its prime and was an excellent rival to .NET and Java, mostly because engineers loved the ease of coding with it. It was also easier to set up and maintain a RoR on Linux than a .NET server on Windows. These two properties (and many more) caused many startups to add it to their tech stacks. And they were not wrong to do so.
NodeJS was also an upcoming and emerging technology. Performance wise, it was superior to RoR. That wasn’t the game changer, adoption was. Any JavaScript / Frontend developer did not need to learn an additional coding language in order to write backend services. Maybe that was the reason for the emergence of “Full Stack Developers” (whatever that means).
By inspecting GitHub’s pull requests statistics through the years, it can be seen how JavaScript and Node.JS had become the dominant technology on RoR expense, around 2016. Back in 2012, no one could have anticipated this.
Betting on the wrong technology has its consequences. Although RoR is still an excellent technology in 2021, its decline has an effect on recruiting. Engineers do not wish to work with declining or obsolete technologies. Not only out of no interest, but for fearness to their careers. Using Legacy technologies prevents us from recruiting good engineers. The other way around is also true. If we can not recruit anyone to maintain our technology, it turns into Legacy.
Always using superior and latest technologies is not always a beneficial strategy. I remember dreaming about Rust back in 2017. Besides a learning curve quite hard to overcome, it was superior to any other language. At Silo we played around with the idea to code our server side applications with Rust and even Silo’s IoT device. It’s now 2021, 4 years have passed and while it is still superior and getting more and more attention it still hasn’t caught on. You can not recruit enough engineers experienced with Rust. Similarly, there is also a superior technology to Node.JS called Deno. It’s 3 years old today and still hasn’t caught on. They may both rise one day, they may also decline and become obsolete. The success of a technology is not only about its technical properties but also about unpredictable trends.
Whether we bet right or wrong, it’s events beyond our control that would eventually turn our application into a Legacy. It’s always only a matter of time.
Next we would be talking about another evolutionary process, one that ends with a refactor to our application.