Should you ever rebuild your software product from the ground-up?
Apple has announced that it will be rebuilding its Maps application from the “ground up”. To be fair, its Maps application is pretty terrible. To get a sense of just how far behind the competition it is, this excellent blog by cartographer, Justin O’Beirne, argues it will be almost impossible for Apple to catch Google Maps. It highlights how Google, from matching different datasets together, is now, incredibly, creating “data out of data”.
As a result, Apple has decided to rebuild a core application in its mobile ecosystem. It’s a major decision that executives won’t have taken lightly. So this brings us to the key question that I want to examine: when should you accept that a software product is no longer working, and you need to completely rebuild it, with all the associated investment?
Apple has tremendous resources at its disposal, which means it’s well positioned to make this decision – it can keep its existing Apple Maps application running, while working on the new version (reportedly four years in the making). However, for the majority of businesses, maintaining two versions of the same product is prohibitively expensive – it’s tough enough with just one core product, staying on top of existing technology, satisfying changing (and demanding) customers, and avoiding falling into technical debt.
For most businesses, it’s rarely the right decision to start from scratch. I recognize it can be tempting to look at a new, powerful technology, and think to yourself, how much better would our product be using it.But I urge caution: it takes time to build a new software product (remember Apple has spent four years working on its Maps revamp). By the time you’re finished, the market (and your competition) will have moved on, and you may find yourself even further behind. Just remember what happened with Netscape, when it decided to rebuild from scratch. The company was so late with the “new and improved “ version that it opened the door to Microsoft’s Internet Explorer to take over (the blame has been put on Microsoft’s anticompetitive practice of bundling IE into Windows, but if Netscape had maintained its leadership they could have been able to fight, just like Firefox or Chrome do nowadays).
Also, remember that new code isn’t perfect. You’ll need all the associated investment in a strong quality assurance team, to ensure the rewrite doesn’t face the same problems as your existing product.
Prevention is better than cure
So how do you avoid getting into this situation to start with? From effective application portfolio management, to early investment in testing and quality assurance, there are well-known approaches. However, I’d like to highlight some of the strategies that I see companies that we work with using (and to be clear, this is not a complete overview, but ideas to consider when making your decision):
- Hire grey-haired developers. If you’re building software well, then it is designed to change and evolve over time. This means thinking about the dependencies and the bigger picture of the product you are building. This is why it pays to invest to bring onboard early the “grey-haired” developers, who understand these trade-offs, and can help build better software from the start.
- New technologies mean you don’t have to completely rebuild. In this strategy, you use APIs to build new front-end services and products, on top of your legacy environment. This is the strategy many big banks are using to compete against fintechs – rather than starting from scratch, they’re opening their systems via APIs, and building new products and services together with third parties. Technologies like WSO2 or MuleSoft are low cost and enable you to add-on APIs and service bus to older technology.
- Code refactoring helps lower the risk, while making improvements. Choosing to refactor your code means investing in improving your code and product, but avoids the risk (and headache) of a complete rewrite. It’s a fundamentally different proposition from starting anew.
- Startups invest in their base technology. With the startups we work with, we advise and guide them on how to be effective in investing in R&D in the base technology. This means understanding the trends, investing in the right architecture, and making long-term decisions early on in the product life cycle. For startups, there’s tremendous value here in working with experienced partners, that have been there before, and can provide guidance on decisions that will impact the product and company years down the line.
Taking the plunge and following in Apple’s footsteps
In an ideal world, it should not be necessary to “reinvent the wheel”. However, when products don’t have a solid foundation or are not built to scale, in some cases the only option is to start from scratch. For example, here at Belatrix Software, we worked with one of the leading providers of video on-demand services when they re-architected and re-developed their video solution (both when the company was a startup, and after when it was acquired by a multimedia giant). We helped them migrate from Flash to AngularJS, as Flash was becoming obsolete.
During the process we kept both versions running, but the cost was huge – we were making updates to the old version, keeping the business and product running, while simultaneously investing time in creating the new product. We took the decision to write the code from scratch, and the business rules were the only part unchanged. Here the final product was a major success, but it was a major undertaking. However, given the decline of Flash, we believed this was the best option (and ultimately helped it get acquired by the multimedia giant).
Although software is meant to evolve, in situations where the technology has advanced so dramatically, you may be better of starting from scratch. However, when your software has solid foundations, and it’s not too late, it typically makes more sense to refactor your code, and work on iterative improvements.