The hidden costs of feature parity

Scope creep

The in-house development team, which was in charge of migrating a native desktop application to their new cloud infrastructure, raised major concerns about the scope of their 2.0 release.

Their previous desktop application was the top-used client during patient visits used by medical staff in clinics. Its main goal was to support uploading measurement data to the cloud from all the glucose meters they manufactured and help doctors evaluate their patient's most recent health records.

The original version was a full-fledged client application supporting different user roles and the same features their diabetes platform could offer following a successful log-in.

However, with all the new features and advanced authorisation options of the new API, it would have taken the team too much time to integrate them. This application was crucial in the new ecosystem and patient visit ceremony. Since we could not let this client application delay the entire release, we had to jump in and help the team figure out a new strategy for the implementation.

Decoupling responsibilities

Anyone who has ever worked on legacy system displacement probably has heard a version of this well-known phrase:

"Replicate the same features the current system has!"

It seems harmless at first glance and is a fair requirement from the stakeholders' perspective. Gather all existing features and implement them using modern technologies. But this sentence alone could lead to a lot of unnecessary expenses. Let us see why.

Sometimes, when we work with legacy systems, we have to compromise on our solution or take extra routes to achieve what we want. Over the years, this can generate a lot of noise in the old system that we want to avoid replicating in our new version. That is why, when thinking about migrating a legacy system, we must carefully examine each functionality and ask some critical questions to avoid the feature parity trap and get rid of all unwanted features or find the right solutions for our problems:

• Why did we have this feature in the first place?
• Do our users still need this functionality?
• Is there a better way to solve this problem?
• Is there even a problem that needs to be solved?

While considering these questions, we quickly realised that the renewed web application already solved almost all required features except those related to meter device communication since they require driver-level communication.

We devised a plan to keep only the physical device communication in the native application, like uploading to the cloud or editing meter device settings, and redirect all other features to the modern web app.

Zero-maintenance features

Executing this strategy, we helped the team cut a massive chunk of their scope, which enabled them to deliver on time, allowing a successful launch a couple of months later.

This solution not only saved money on unimplemented features before the launch but also unmeasurable expenses on future maintenance costs. Based on the original plans, our client would need to update this application regularly when they release new features on their diabetes platform. Currently, they only have to update their desktop application when they release a new glucose meter or when they have a bug to fix.

When migrating legacy systems, we can not rely on the old system's feature set and behaviour alone because that will also lead to migrating all the old system's flaws. If we examine the purpose of each feature, we might realise that modern technologies allow us to implement better solutions or eliminate those problems by default.