If you have software that isn’t meeting yours or your customer's needs, you may be wondering if you should completely rebuild it. Here are some strategies to avoid rebuilding the software you already have.
If you’re reading this blog post, you probably own or work on a software product that needs some major modifications.
Maybe it’s no longer performant, or you’re not solving the right problem for your customers. It might feel dated, or perhaps there are some linchpin dependencies that need to be upgraded because they will no longer be supported, and the new version has breaking changes.
Something’s gotta give—but the thought of a total software rebuild may make you shudder, especially when you’re acutely aware of how much time and money went into your existing product.
Rebuilding software is a huge investment, and it will be a long time before your users see the benefits of your development team’s hard work. With a software rebuild, you’ll have to start over completely, even writing code again for elements of your software that currently work for your business and users.
If you already have working software, or you have read my recent blog post Rescue or Rebuild? Knowing When to Start App Development Fresh, here are some strategies to extend your software to meet your needs that do not involve a full application rebuild.
Audit the Software
Before you can get started adding new features, you need to take a step back and evaluate what you currently have. You need to know your software product’s strengths and weaknesses, what is bullet-proof and what isn’t, and, most importantly, what your customers actually need — which is not necessarily the same as what they want.
Performing a technical audit will allow you to uncover performance bottlenecks and features that need more testing, while a user experience (UX) audit will find changes that need to be made to workflows, experiences, and interfaces. It is important to perform both of these audits so that you fully understand what will need to become part of your software development process.
For both kinds of audits, make sure you select the right team to conduct the reviews.
Your technical audit team should have a broad range of expertise and experience so that you can judge everything from your coding standards, to security, to data storage, to architecture.
For your UX audit, one of your main goals will be to eliminate bias, so your team shouldn’t be full of superusers or people who are already very close to the product.
For both audits, you should create, follow, and document a clear process so that your results are easy to organize and review. This will be a huge help when it’s time to start taking actions based on what you’ve found.
Make Small Incremental Changes
When standing before a daunting task, I often have to remind myself that you eat an elephant one bite at a time. While the overall goal is monumental, you can take a longer series of small steps to achieve that goal. Armed with the knowledge you’ve gained from your audits, you’re ready to define a roadmap, and, if you’re still here, you’ve decided that to completely rebuild the front end of your software is not a viable step for your roadmap.
Your roadmap is a series of small steps toward your goal. You don’t go on a family road trip to the Grand Canyon by just getting in the car and driving. You have to plan and make pit stops along the way for fuel, food, rest, sight-seeing, etc.
The roadmap for your software development is no different. You need to map out how you are going to achieve a larger goal. For the front end, this can be challenging. All of the pieces to your front end are there, but they likely need styling improvements, or when necessary, some new components.
Instead of tackling everything at once, use the results of your technical and UX audits to inform the steps you take next.
Follow the Open-Closed Principle
The open-closed principle comes from object-oriented programming and states that your software code should be open for extension but closed for modification.
If your current application programming interface (API) is not meeting your needs and requires some major work, for example, create a new API that proxies to your old API. This will allow you to replace parts of the API without having to completely rebuild the entire API. It also gives you the added benefit of defining a new and better contract for your API than the one you currently have, because you’ve learned a lot about your software since that API was originally built.
You might think it sounds contradictory in a blog post about avoiding a software rebuild to give advice on replacing parts of your API — but what’s important to note is that no matter what, there will be times when certain parts of your software needs to be replaced.
However, that doesn’t mean that all of your software needs to be replaced. Additionally, there will be times when your software needs to do more than it currently does, and in those cases, it can be extended. Choosing to extend rather than rebuild will save you a crazy amount of time.
When modifying your software, it’s important to have unit and integration tests in place. This will save you from breaking existing functionality.
Do not skip this because it is hard, or because you did a manual test and it worked. If the software code is hard to test, then you may not be following best practices or trying to test too much at once.
Having an automated test suite has saved me countless hours of debugging and many after-hours calls to triage issues. Do not skimp on the tests.
That Doesn’t Sound So Bad…
Those strategies don’t sound bad at all, do they?
When you modify or extend instead of rebuilding, you may not see the initial velocity of features being shipped that you might see with burning your software to the ground and starting over, but you will be able to incrementally deliver value to your customers. This will keep existing customers happy and attract new ones, because they will know you’re actively working to make their lives better.
You may feel overwhelmed by the current state of your software, but remember: a journey of 10,000 miles starts with one step.
If you’re ready to start modifying your existing software and you’re looking for a partner, get in touch with one of Very’s development experts today. We’ll share how our team can walk with you through all the steps above.