Rewriting Your Software Product? Read This First.
So you just received the 10th customer complaint over the same issue you thought was fixed three weeks ago.
Your heart has been racing for what feels like months straight, and you can’t even glance at the customer support log without a freight train of anxiety hitting you.
You know your software product is buggy. It seems like your developers are producing more bugs than features, and they insist that the software is just too much of a mess to work with.
You’ve come to the very hard decision that a total rewrite is necessary in order for your product, and your sanity, to survive…
But wait! There are different ways to approach a rewrite that doesn’t necessarily entail throwing away the original product. Below are a few suggested questions to ask yourself and actions to take.
Ask Yourself, Why is this Rewrite Necessary?
You really need a rock solid answer to this. If you can’t articulate this to yourself or a colleague, you aren’t ready to invest in a rebuild of your product.
It’s easy for the frustrations of customers and complaints from your development team pressure you into blowing up a product and starting new, but it’s important to know the cost / benefit of doing a rewrite before jumping in.
Write down on paper the justification of the rewrite so when you inevitably think “is this really necessary?”, you have a clear reminder of why you’re doing it.
To help you ballpark whether or not a rewrite is necessary, here some common signs it’s time to scrap and rebuild:
- Small changes result in unexpected bugs in seemingly unrelated places
- Your development team is often hesitant and / or pushes back on feature work you send their way
- You want your product to move in a new direction that it wasn’t design or engineered for
- It takes significantly more time and money to onboard developers than it should
- Simple bug fixes take far too long to complete
Narrow Down the MVP of Your Rewrite
Approach the re-development of your software product as if you’re aiming to build another MVP.
The challenge of re-writing a product is that (usually) you aren’t introducing anything new, you are trying to get back to where your 1.0 product is feature wise.
For example, while working on the new web banking platform at Synchrony Financial, it was decided that rather than completely rebuild every feature of the legacy platform on launch day, we simply linked to old parts of the platform for non-mission-critical features.
We omitted the ability to create new banking accounts, since the signup flow was a significant undertaking. Instead we focused on existing customers and their ability to manage their accounts. Editing your profile was delegated to the legacy platform, as well as requesting paper checks, and other things people generally don’t spend much time on.
While the end result isn’t a picture perfect experience, for the most critical user paths, it works great. This saved months of development time, and most importantly, saved dollars.
Explore an Incremental Rewrite
Rather than blow up your product entirely, figure out whether or not you can gradually replace existing components of your software, and do incremental releases. Often times you don’t need to start from zero!
This isn’t always possible, as the nature of a spaghetti code system is that components are so tightly dependent on one another that it makes it extremely difficult to update any individual component.
Your development team will know best whether or not this is a possible path, but an incremental rewrite can allow stability to reach your customers much faster than a waterfall style rewrite.
Buy What’s Broken…
Are there pieces of your software that can simply be bought as a SaaS or PaaS product?
It’s 2020, and software is cheaper than ever. Especially software that helps you build software! There might be a piece of your product that can be “outsourced” to a vendor.
Perhaps you have a custom built CMS, or maybe you decided to use open source software because it was free rather than pay a subscription for something premium.
User authentication causing problems? Find an authentication as a service provider.
Nobody likes to increase their monthly bills, but if a $50 / month subscription saves you $5,000 and 140 development hours, it’s a no brainer.
Reduce Development Time
It’s not uncommon for developers to re-invent the wheel for common problems. When going through with a rewrite, you need to find any areas you can save time and money in.
If you aren’t very technical, this may seem like mumbo jumbo, but if your development team is solid, they should already be thinking about this stuff.
If you have a lot of complex forms in your UI, seek a solid form library.
Rather than build custom UI components, use a library like Material UI or Semantic UI and change the styling.
Don’t have the resources to manage a database and API? It’s 2020 dude! Serverless tech is mainstream. See if something like Firebase firestore + authentication + functions fits your needs and save yourself a ton of time.
The point is, buy / use other software to ease the development of your own. Try to stick to well supported technologies, otherwise it can be just as bad as rolling out your own solution.
Aside from the time & money you will save on development, you will also save a ton of time finding & onboarding developers (if you’re fortunate enough to be able to bring on more devs).
Get an Expert Opinion Before Rebuilding
Maybe you don’t have an in house development team. Perhaps your product was built by an offshore team you hired on Upwork, and now you have one or two developers around to maintain it.
Sometimes you just don’t trust your developers to evaluate the necessity of a rewrite of your product.
Or maybe you don’t feel like you have enough information to come to this decision yourself.
In this case it’s a good idea to invest in a consultant who can spend time to understand your product, your customers, and your current position.
If you happen to have a web product, I can definitely help you determine whether or not it’s time to rebuild your product, as well as recommend any better alternatives.
Understand What Went Wrong
If you and your development team can’t pin down exactly what is wrong with your current product, then you aren’t ready to rebuild it.
A rewrite doesn’t mean throwing the old code out the window and blindly starting new.
The old product bundle of lessons learned, and a rewrite should come after you have understood all the lessons it had to teach.
Understand The Costs
If you are rebuilding your product, then you should understand by now that there is no substitute for quality.
However, this quality will likely come at a higher cost than the development of your legacy product (not always the case).
It’s important not to commit to a rewrite while prioritizing cost savings over the quality of your product.
Bad developers at a low rate will cost you far more money than good developers at a high rate.
That being said, good developers on a shoe string budget aren’t magicians either.
Make sure you have the resources to sustain a realistic timeline with a scope up work that will set you up for success, not a second failure.
Speaking of scope…
Clearly Define the Scope
Once you get past the dread of having to rebuild your software, what awaits is a world of endless possibilities.
The famous “if you could start over, what would you do differently?” question becomes a reality for you.
You will want to implement all of the amazing ideas you have that you couldn’t execute before.
Don’t do it. As sad as it is, try to keep a little bit of that dread around, because it will keep you level headed enough to humble the scope of your rewrite.
Often times a bad product is the result of too many ideas executed on too few resources. The last thing you want is for your 2.0 to work as poorly or worse than your 1.0.
As I mentioned in the first point, if you approach rewriting your software as you would an MVP, you will likely steer clear of this issue.
Conclusion
If you are in the position where you are debating a rebuild of your software product, I hope the above points have given you plenty to think about!
It’s rarely a cause for celebration when you come to the conclusion that rebuilding your software is necessary, but if done correctly, the end result can take your business to heights not previously possible.
If you have a web based product, and need a software engineer who can help you analyze, plan, and / or execute a rewrite, I’d love to help you out.
