Technology Debt in Software Frameworks
I could literally watch my technology deteriorating. My releases were always late. We had too many bugs. The UI felt old. That was when I used to head the R&D and product management of a cloud-based B2B solution. The solution used Java as the backend and Angular JS as the frontend UI framework. While the Java code was more than 15 years old, it performed well in the Docker containers. It was the UI framework I was worried about.
Angular JS had a few minor releases with only some APIs breaking over three years. When Google, the lead maintainer of the Angular UI framework, upgraded the framework to Angular 2.0 in 2016, a binary break to the 1.x versions was introduced. We hesitated to upgrade from Angular JS 1.x to Angular 2.x or newer because we knew it would mean a complete reprogramming of the User Interface. Meanwhile, the technology debt kept growing.
When the technology debt had grown too big in 2018, we started coding some of our UI with Angular 5. But then there was another challenge. Angular changed major versions faster than I could keep up with. Sometimes, three major releases we introduced with a variety of API incompatibilities within 12 months. While we tried to catch up with the existing technology debt, we already collected new ones. This was a costly exercise. It was a vicious circle. While I have left that show to work at the Qt Company last year, I’m afraid my former colleagues are still struggling with it. To keep things interesting, Angular is considering introducing a micro frontend architecture now. I wonder what that will mean for existing products.
If I learned anything from the years of working with Google’s Angular JS and Angular, it is that one should think twice about which technology framework to use for a solution with a long lifetime. If one develops apps that are supposed to last for more than five years, then the latest, hyped technology might not deliver the best total cost of ownership over ten years.
Protecting Your Development Investment
Technology debt is like human aging. You just can't avoid it. Once you ship your first version, your software complexity will grow, and you will start collecting bugs. There is no single way to manage technology debt for applications with a long lifetime. But some known preventive measures include:
• Managing your backlog to balance new features and quality
• Creating a culture that allows calling out technology debt
• Simplifying refactoring with a micro-services architecture
• Endorsing code reviews and code documentation
• Proactively plan your technology evolution for five or even more years
Planning a long-term technology roadmap can sometimes be low on your priority when you simply focus on getting that big deal or the next release out. However, there is a good reason to prioritize it anyway. You are probably busy enough with the technology debt your R&D team is creating on its own. Hence, you probably want to minimize technology debt caused by external factors such as binary breaks or deprecated APIs in open-source technologies.
Every open-source UI framework and every software development kit will also have some technology debt. Some cause more disruptions, some dramatically less. I did describe earlier the challenges I had with Angular (JS). Some other UI frameworks for mobile app development behave like Angular with no guarantees of API stability for even two years. On the other end of the spectrum are software development platforms like Qt. Qt offers a Long-Term-Support (LTS) release every 18 months, which provides code backward compatibility and API stability for five years, sometimes even longer.
This stability helps you, at constant developer resourcing, to:
• accelerate your time to market with less developer time spent on technology debt
• predict your release roadmap better because of fewer external influences
• improve developer satisfaction because fixing one's own bugs is terrible enough
• plan your technology roadmap in synch with Qt’s predictable release schedule
Naturally, also the Qt framework collects technology debt and we have to clean up our code eventually. But Qt has a softer approach to handling technology debt than some other frameworks. In 2020, Qt did introduce a major release which was not 100% backward compatible with the previous release. The previous release did carry a good amount of technology debt from many eight years of product enhancement. Qt provided upgrade migration tools for customers to protect their investment. In addition, Qt also offered an additional two years of support of the previous release at no extra cost for subscription customers to protect their existing investment. That adds up to over 12 years of backward compatibility in the Qt 5 series and a clear migration path to the next major release.
Everything is aging eventually. It's our choice how we want to deal with technology debt in software applications. If you want to know more about the Qt framework, check out this page.
