So, you’ve decided to rewrite your software. The entire team is ecstatic. No one will have to deal with the old, hard-to-use, painful-to-extend mess anymore.
Since you already have working legacy software, you have the perfect specification for the new product. Planning what to do should be easy right? Not exactly. Creating software from scratch is all about “what can be,” but rewriting software has to start with a clear understanding of “what is.” And your existing application probably does far more than you think.
Before you jump in with both feet, take time to do some research. The better your information, the better your software will serve your users, and the happier everyone will be at the end of the day.
1. Research Workflows Thoroughly (or “Where did that function go? I needed it!”)
In some ways, recreating a program is like remaking a movie — people have lots of expectations. With a remake, there are scenes people need to see, favorite lines they’re waiting to hear, and beloved characters you aren’t allowed to change. Your existing software may not have “fans” in the same sense, but it has a myriad of uses that people simply can’t live without.
The problem is, even if you review your existing app and note all of its stated functions, you’re still going to miss things. As time goes on, a software application can take on a life of its own as people find new ways to use it, new work-arounds to make it meet their evolving needs.
So how do you figure out what you don’t know about your legacy application? Focus on the users rather than the software. Instead of asking “What does my current application do?”, ask “How do people use my current application?”
Understanding your users’ workflows might require ethnographic research, surveys, and shadowing people on the job. All the data should then be mapped to help you find connections, understand relationships, and (hopefully) identify redundancies that can be streamlined.
When you start with workflows, you can create software that makes users’ jobs easier instead of more confusing.
2. Consider all Related Interactions
No pieces of software stands alone, so your research needs to include technical iterations, including:
Almost all large software applications collect and track data. How much, or what parts of this data need to be migrated into the new system (e.g. are you simply migrating users and passwords, or also including all their history)?
If you are replacing an internal workflow application it’s likely some smart analyst at one point in time built a small utility to help herself and other analysts do their job better. Do these types of tools exist in your system? How do the tools get their data? Heaven forbid, do the tools write to the production data set?
With large applications, reporting happens. Interestingly, that reporting commonly happens outside of the system in analyst spreadsheets. How is reporting happening with your system? What tools are being used? What data is needed? Is there an opportunity to streamline a lot of important work that is happening in inconsistent and non-backed up ways outside of the system?
Considering these before the project even starts will help you set reasonable budgets and avoid unpleasant surprises once design and development start.
What other components did you consider for your software rewrite?