.webp)
You might be surprised how much time R&D teams spend on fixing breaking APIs. Imagine you are the Head of Product, and your R&D team just finished a ground-breaking product after two years of software development. You are ramping up and fine-tuning the production with various global variants for six months to crank out that new product in volumes. Shipping large quantities of products, you get customer feedback that you haven’t received before, and you ask your R&D team to improve the software. Now the R&D team tells you that - instead of only fixing the customer issue - the team also needs to fix the APIs of the product because the latest release of the cross-platform UI toolkit broke several of the APIs you are using. Instead of spending a few days to the customer's issue, your team spends weeks updating everything, including API documentation and integration tests. Does this sound like an unrealistic scenario?
According to a study conducted by Forrester Consulting in March 2021 and commissioned by the Qt Company, 42% of embedded device and connected product development directors think that too much time is spent maintaining or updating what we have. The problem seems to be real. What causes it?
API stability of cross-platform frameworks cannot be taken for granted. While every cross-platform framework or UI toolkit has API compatibility policies, you might be surprised if you dig deeper into what the “policies” of some framework providers allow. It might be that the maximum guaranteed API stability is only one year or a few releases (which new emerging platforms sometimes publish quarterly). The provider of a cross-platform framework might break an API if a change in the framework is considered "valuable" and you don’t react within 72 hours to your software breaking as an outcome of the change. Who judges what is “valuable”? The framework provider itself. Not you. This assumes that your R&D team has created already test cases, has submitted them to the framework provider, and they have been accepted before the breaking change. Otherwise, it might go unnoticed that a framework API change will break your software. Still, you might have only 72 hours to react before your test is removed from the compatibility criteria. Are you sure your team has time and priority to react to an API break not caused by you but by the framework provider while you are in the middle of building a global success and you want to listen to your customers instead?
While nothing lasts forever, product leaders should look for the ideal balance between innovation and stability of their products. Makers of digital products can choose cross-platform frameworks which guarantee API stability for up to 5 years. This reduces the time spent on fixing APIs dramatically over the lifetime of the product. This enables a R&D team to focus on innovations and strategic initiatives instead of “keeping the lights on.”
The Qt cross-platform framework guarantees API stability up to five years based on one of its Long-Term Support (LTS) releases and extended support agreement. In some cases, like in the Qt 5 framework series, the API stability has even lasted eight years. Product leaders can select between the latest features in one of the predictable six-month releases or choose a LTS release. Every third release of the Qt framework is a long-term supported release. High-volume, digital products with long lifespans and complex global variant processes can be designed, built and tested using a Qt LTS release and its integrated tool chain. API stability does not have to be black magic.
Product leaders can have the power to balance innovation and stability themselves by choosing a cross-platform framework with an API stability of several years.
If you want to know more about Qt's Long-Term Support releases and extended support options, please make sure to contact us.
