Why Your App/System Rewrite Will Probably Be Bigger Than You Think

If you’re doing a major rewrite of an existing app, you may be hoping to simply duplicate the existing app’s basic features. Unfortunately, it’s not that simple.

Your users have come to rely on the set of features they use in your current app. And if they can’t accomplish all the same tasks/goals as they did in your rewrite’s first release, they’ll be very disappointed.

Don’t believe me? Let me give an example from the world of video games.

Sports Video Games & the Problem with System Rewrites

Every five to ten years, an all-new version of the Xbox/PlayStation/Nintendo is released. The new system is undoubtedly faster and more powerful, so games will be bigger, have better graphics, and use more realistic physics that the new processor can handle. It’s an amazing new world for the video gaming market. Except for the sports franchises (football, soccer, hockey, basketball).

Unlike any other genre of video game, a new version of the sports game you love is released every year, featuring slightly better graphics, tweaks to the gameplay mechanics, and maybe even a new game mode. For five to ten years, major sports video game publishers push out iterative versions of the same game, each time making it a little bit better.

But when that new console comes out, sports game makers have to scramble. They have to rebuild their games on new technology, utilizing all of the power and capabilities. Instead of having a year to iterate on games, making slight adjustments, they now need to rewrite them from the ground up in the same amount of time.

At $60 per game, each year, consumers are essentially paying for updates to the same game. And for the most part, it can be argued that these updates are worth it. Each game provides many hours of entertainment, and if no one were to buy it, the game would cease to exist.

But by the time that game hits the the seven- or eight-year mark on the current system’s development cycle, the consumer (or user) has gotten pretty used to all of the great gameplay enhancements, features, game modes, and so on. The game has reached a certain level of expectation.

Consumers expect that when the latest version comes out each year, it will have all of their favorite modes and features from the previous year. But when the game has to be completely rebuilt from the ground up, developers have to start cutting features to make the deadline.

Consumers are not happy.

The Problem with System Rewrites

Atomic uses an Agile approach to work towards a focused, valuable first release for every software product. With brand new software, this can be small(ish) and can be developed relatively quickly.

But a valuable first release for a system rewrite has completely different standards. No matter what’s wrong with your current app (bad usability, outdated tech, bugs, etc.), the end product has one core requirement — feature parity. Users need to be able to accomplish everything with the new app that they could do with the old one.

Whether you’re dealing with an internal ERP application that runs day-to-day tasks for your employees, or an external app that allows users to run detailed market reports, releasing a new version of the product without feature parity will create backlash amongst your users.

Unfortunately, when it comes to time and budget, companies often want to push seemingly minor features to the icebox, denoting them as non-essential items that won’t be in the initial release. From a user’s perspective, though, it’s not acceptable when they can no longer do the same task they did yesterday because of a “new” application. Users will lose trust in a system if they cannot do everything they expect to do. This is especially true for internal systems.

Option #1 – Change Your Expectations for Employees

When features are cut from the initial release, some tasks will become more difficult (or impossible) for employees to complete. The easiest option is to change your expectations.

For example, say your current system allows complex version control and approval processes, but those features won’t be available in the first release. You should be prepared to adapt the workflow and loosen control.

You could create a more-complex manual workflow to replace the one in the old software—and expect the same levels of accuracy and efficiency from your employees. But that’s a recipe for disaster.

Option #2 – Change Your Processes

It’s possible that your processes were created before custom software. And that large parts could be restructured and simplified. Are you willing to dramatically change the ways you work?

My colleague Jonah describes this as the User Goals approach, and it will have you asking questions like:

Do we need what we think we need? Is there a way we could restructure our business to be more efficient and allow us to use less software? Which of our software’s tasks can be combined, re-imagined, or removed altogether?

This is challenging, difficult work, but it can be extremely rewarding.

Option #3 – Be Prepared to Adjust your Budget

If you cannot change your workflow processes, and all features from your old application need to be in the new one, the last option is to be prepared to increase your budget beyond any initial estimates.

All rewrites start with mapping your current system’s features and functionality. But no matter how much research and time is invested, new functions and edge cases will turn up throughout the project. Internally, we’ve come to call these Last Thursdays. As in, “We always do (insert process) the same way, except last Thursday when we had to do it differently [and the software needs to be able to do that].

“Last Thursday’s” will almost never come up during our Research, Design, and Planning phase. They just aren’t top-of-mind of the users we are talking to about their workflows and responsibilities. They always come later, sometimes early enough, when we are still doing initial wireframes, but sometimes, after a feature has been developed. (Jonah describes this process in his post on Why Software Rewrites often Fail.)

These new functions will increase your scope because they have to be in the rewritten software—pushing back your release date and likely adding to your budget. As you go into a project, be prepared to adjust your MVP as needed to avoid releasing an incomplete system.

What a Successful Rewrite Looks Like

We start all of our projects, whether greenfield or rewrites, talking about what success looks like. These are often lofty goals of increasing productivity, decreasing frustrations, eliminating software failures, etc.

But one goal for rewrites that is never high on the list: That your users don’t notice it is new software; or they only notice a new UI. When users start to notice missing features or drastically different workflows (especially without warning or training) there will be a backlash.

Shipping software often and early is a great mantra, but make sure that it’s complete before doing so.