Back to main page
7 Lessons I’ve Learned About How To Rewrite Software.
In today’s software industry, things move fast. New standards pop up frequently and code needs to be adaptable to changing demands from both clients and competition. If you’re not working in CI/CD, chances are you’re not building a successful product.
But how do you apply an agile approach to a situation where you need to rewrite software? Not every project will have you starting from the ground up. Maybe someone has asked you to freshen up an app they built a few years ago. Maybe you’ve been given a finished product to work with but the codebase is a mess. Or maybe it’s time to optimize something tried-and-true for a new development language.
Though needing to rewrite software may seem daunting, they have the power to make old software more usable, more efficient, and much longer-lasting. You just need to know what to look for, which questions to ask, and how to execute your ideas once development gets going. Here are seven tips to start you off.
1. Ask yourself why.
The first thing your team should establish before any rewrite is why you’re doing it. Determine which issues the software is facing, what benefit the client will get from a rewrite, and how the overall product will improve once you’re done. Thinking about these questions early on will give you a clear focus and ensure everyone’s on the same page come delivery time.
As a general rule, there are two main reasons why it might be necessary to rewrite software. The first is quality. If you’re looking at an app that’s full of bugs or written on a platform that’s no longer supported, a rewrite can be really beneficial. Not only will it help improve the software’s functionality, it’ll also give you the opportunity to migrate your codebase to a development language that’s more future-proof.
Efficiency is another popular reason why people choose to rewrite software. This kind of request will often come from the client side as a result of user feedback or testing. For example, if you were rewriting an e-commerce app, you might be asked to rework its user flow to make the product adaptable to multiple use cases, or to reduce the number of clicks required to purchase an item.
2. Get to know the software you’re rewriting.
Once you’ve made it clear why you’ll be rewriting something, it’s time to get to know it. Use the app from start to finish and familiarize yourself with what works and what doesn’t. Dig around user feedback and backlogs and document previous issues that have come up. And don’t forget to look over the old UX/UI to see what could be improved. All of this will help you understand what you’re working with, what to avoid, and what direction to take as you rewrite software.
During this step, don’t bulldoze over things that work well. This will save your team time during the rewrite process, but it’ll also keep the app’s user base happy. People don’t like having to relearn an entire flow of actions if they don’t have to. So remember to pay attention to the original code’s strong points when looking out for what to overhaul.
3. Think about migration.
As you move forward, think about any potential problems that might come with keeping old features during the rewrite. Let’s say you decide to maintain the current framework for allowing users to log into the app. You want to be sure that your updated version doesn’t log users out. This may seem like a minor point, but details like these add up, and they’ll make the difference between a good final product and a great one.
Here’s another example. If you’re moving to a new development language, think about your analytics tools. On a recent project, we had to take a hybrid app built in Xamarin and turn it into two native apps, one for iOS and one for Android. Though our client would have liked to convert the original analytics project into two separate platform projects, this wasn’t possible and we had to start analytics in each native version from scratch. Luckily, we discussed this ahead of time, which helped avoid any misunderstandings once development started.
4. Be aware of your business requirements.
When rewriting any kind of software, it’s essential to maintain frequent, transparent communication practices with your client. Get as much information about their expectations as possible, and make sure your team has access to it throughout the rewrite process. It shouldn’t be static, either. Check in regularly to see if any changes need to be made after testing or client feedback, for example.
This is one of the most important steps any time the decision is taken to rewrite software, because it helps ensure you’re taking the app in a direction that meets your client’s needs. The alternative to this is figuring things out on your own, which takes time, money, and guesswork. It also comes with its fair share of risks related to miscommunication.
Here’s a simple example. Say a project gets started and your client decides that a button in the app should change based on users’ actions. Now imagine one of your designers wants to rework the entire app’s design around a black background, but doesn’t know that one of the user actions will make the button turn black. If this information isn’t exchanged very early on, you could find yourself with a mess on your hands when delivery comes around—one that could have easily been avoided, too.
5. Remember your project risks.
Before you begin to rewrite software, be aware of any risks that might come with the project. A common scenario when people start to rewrite software is “the one-man show.” If a single developer has made every decision about the app you’ll be reworking and all questions and changes need to go through them, plan ahead for this.
Try to get your hands on the old code base, to see how the previous version of the app was built. Think about access to development platforms (Firebase, App Center, etc.), which you’ll need to build features like push notifications and analytics and distribute in-progress versions of the app to testers. And don’t forget about access to distribution platforms (Google Play Publish, App Store) – anytime you rewrite software like this you’ll need access to platforms like these to push the new version of the app to live.
Knowing what kind of access, information, and tools you have available as you rewrite software—and what requires permission from the client’s side—will help avoid the entire project coming to a stand-still if anyone who holds the keys to the old software becomes unavailable during development.
6. Put your expertise to work.
If possible, when you rewrite software you want to have developers on hand who are familiar with the platform the old app was built on. If any questions come up about how technical issues were solved in previous versions, they’ll be able to help. So, if you can, before you rewrite software try and get access to the person who built the original app, too. They can clarify any code logic that doesn’t make sense to you—even though it was definitely put there for a good reason.
As the project’s focus shifts towards a new platform, use the expertise in your own team. Remember that any migration comes with its fair share of differences and limitations. Don’t force everything to be exactly the same when you rewrite software, especially if it can be done more efficiently or elegantly on the new platform. You want to know the old app but treat the new one like its own project.
7. Use a checklist.
One final thing I do before I rewrite software is sit down with the client and make a detailed checklist of what needs to be accomplished, when for, and what will determine the project’s success. Make sure you go over every potential problem that needs to be solved in the new iteration you’ll be building. This will help structure your thoughts and guide your development team moving forward, all while ensuring the rewrite you deliver is in line with the client’s expectations.
To rewrite software successfully, plan ahead and communicate.
Like any software development project, when you choose to rewrite software the project will come with its fair share of risks, surprises, and challenges. While you can’t predict everything that will happen when you take one on, you can do some smart preparation for it. Know your client. Know what kind of platforms you’ll be working with. And know what can be done to make the new version shine.
Keep in mind that when you rewrite software your approach needs to be flexible. Maybe some old elements are there for a reason, and need to stay. Maybe some things might need to be completely reimagined in the new version. It all depends on the specific piece of software you’re working with and the client’s expectations. So come prepared, but come prepared to change, too.
Need to renew your software?
If you too feel that your software could use a rewrite to make it more usable, more efficient, and much longer-lasting, don’t hesitate to contact us – in addition to the rewrite, Mooncascade can also update your design, fix bugs and even develop brand new features.
