The hidden costs of feature parity

Our partner almost fell for the feature parity trap while working on the 2.0 release of their native application, which would have caused unnecessary expenses and potentially jeopardised the scheduled release of their renewed platform.

Scope creep

After helping our partner finish up the legacy displacement of their decade-old web API, we shifted our focus to build a modern frontend application supporting all the new features their freshly made API could provide. Meanwhile, other in-house teams focused on updating other client applications connected to the ecosystem.

The team, which was in charge of migrating their native desktop application, 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 meter devices manufactured by our partner 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 platform could offer through their web application.

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. This is typically called the feature parity trap.

Before we start planning the migration of any legacy system, we must carefully examine each functionality and ask some critical questions to avoid the feature parity trap and eliminate 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 those functions related to meter devices in the native application, like uploading to the cloud or editing device settings, and redirect all other features to the modern web application.

Zero-maintenance features

By 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 partner would need to update this application regularly when they release new features on their platform. By decoupling all device-related features from the cloud functionalities, now they only have to update their desktop application when they release a new meter device or 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.

Before jumping on your next legacy software migration, try to evaluate each feature with a fresh perspective. You can not just assume all the legacy functionality still has value. You must ensure the features you end up migrating are aligned with your current business goals.