Why Software Rewrites Often Fail – and How “User Goals” Can Fix Them

Over the last few years, Atomic Object has gotten more and more inquiries from companies who want to replace old custom software. These programs are often written in antiquated languages that few of today’s developers know. And most are dramatically below today’s standards for how software should look and act.

Unfortunately, it’s become clear that replacing an old system is often much more expensive than developing a completely new custom software product.

Why Are Rewrites So Expensive?

So why do rewrites usually cost more than creating a new product? In short, because companies don’t know what their software actually does. Here’s how the process usually works between Atomic and client organizations in a rewrite situation:

1. A company maps all official, obvious features of their custom software system.
2. The development team estimates what it would take to make a 1:1 replacement, duplicating these functions.
3. The team starts building, but soon discovers that the old software did a lot more for the users than the company realized, interacting with other software, systems, etc. in ways they weren’t aware of.
4. The company decides to add more features/integrations…then more…and the budget slowly, but steadily, increases.

Without exception, old software systems are more complex that anyone understands, serving users in ways you didn’t imagine.

For example, we had a client who used a custom app to manage all in-person interactions with their customers. They hired us to update the app—duplicating existing features, adding new ones, and moving them from hand-held PCs to iPads.

Unfortunately, when we deployed Phase 1 to the field for testing, the users told us it was “useless.” It turns out the old software didn’t give them the reports they needed, so they’d created a whole additional process of exporting data, then processing it in Word and Excel. Since the new app was on an iPad, they couldn’t export the data in the same way. It was impossible for them to make the custom reports they needed to do their jobs.

When a piece of custom software helps you run your core business, the way people use it grows organically over time. Nobody knows how everyone else uses the system and how all the features interact with each other. Rewrite projects gradually reveal these complexities, then get bogged down in extension after extension to make sure all users get what they need.

The solution to escaping this bog is to forget about the feature set and let yourself approach the project from a “user-goal-centered” point of view.

Business Tasks/Processes vs. User Goals

The problem is not “our business is complex, therefore our software must be complex.” The problem is our approach—both historically and today.

Instead of asking how we can duplicate our existing software with new software built in modern technologies, we should ask, “How can this software help User X reach their goal?” The difference may sound subtle, but it’s extremely important.

For example, the goals of the accounting department (e.g. “safeguard financial health of the organization”) change very little over time. But their daily tasks are shaped by the technology at hand—whether that’s paper ledgers, basic spreadsheets, online payment forms, or complex accounting systems. Accountants don’t come in to work excited to balance a ledger. Instead, they’re passionate about knowing that the financial health they have been charged with stewarding is in a good state. The key to the accountant doing her job isn’t the ledger, spreadsheet, or complex system. The tool could be anything that provides sufficient business value.

This disconnect between topical tasks and user goals offers the unique ability to redefine the functionality required in a rewrite project.

Starting with the End Goal in Mind

Forget making a 1:1 replacement. A software application rewrite is a great place to pause and critically think about what your business needs. How can you do this?

1. Catalog, as much as possible, the functions of the current software.
2. Look at those functions, and abstract out the business needs. Tie activities and tasks to business value.
3. Talk to users to figure out what high-level goals the old software is helping them accomplish.
4. Using what you’ve learned, ask yourself some hard questions. Do we need what we think we need? Is there a way we could restructure business to be more efficient and allow us to use less software? If you start with user goals, you’ll see that some (or many) of the tasks your current software does can be combined, re-imagined, or removed altogether.
5. Work to create an efficient process that makes the best use of everything software can accomplish. Your software consultant would be excited to help you with this step.
6. Imagine how the new software can replace the old in a phased release, piece-by-piece. This approach will allow you to validate the business value of the new system progressively. The alternative of waiting months and years before you see a return on your investment is too risky for most businesses.

By bringing in users at the starting point of your software product development process, you’ll ensure success and release yourself from the prison of 1:1 replacement. You’ll find a scope of work that can serve business and users, and that can be managed for many releases and rounds of work. Your software will be so useful that users in the current system will want to migrate away from it as you release new features that line up with their goals.

Appendix: How Did We Get Here?

If you look through the history of software product development, you can see we’re gradually moving in the right direction. But we’re not there yet.

• The Dark Ages: Developers labored under huge manuals of specifications, written by technical writers and business analysts who didn’t understand development.
• The Dawn of Agile & Extreme Programming: Developers were empowered to define functionality, write, and test software. They could guide products toward on-time, on-budget releases. Unfortunately, developers focused on implementing possible functionality; sometimes, the reason for including a feature was “because we could.”
• Agile & Business Join Forces: Business analysts and managers got involved in the process again so functionality could be informed and prioritized by business interests. Leadership pointed developers in the right direction and validated functionality before release.
• The Infancy of UX & Design: It became obvious that users had trouble actually using the software. Designers were brought in to clean up user interfaces before release; they were asked to give the UI a “look and feel” that would promote user engagement.

Today, many businesses are using software that’s functional, stable, and looks okay—but often has two problems:

1. It’s frustrating to use because it’s defined by tasks, organized around meeting business processes rather than employee goals.
2. It’s failing as the technologies it’s built on are aging.

These problems are compounded by the fact that the functionality in this failing software is now essential to business needs. Companies are faced with huge price tags to replicate functionality perceived as necessary to the operation of business.

What experiences have you had with revamping vs. reimagining custom software?