In custom software, the cycle of write, atrophy, rewrite is all too common. Many product owners too reluctant to embrace maintenance and sustaining engineering. A vicious cycle of expensive rewrites ensues. Businesses feel bruised by developers and experience unhealthy surges in cost and business disruption.
Think hard before deciding to throw away what you have in pursuit of the greenfield: proper maintenance of your software can save your business.
The Narrative
Your business has a need. You decide it can be met with custom software. You hire a development shop and they get down to the industrious work of building your new system. It’s not perfect and it’s a little over budget. A few desired features were deferred to manage costs. As a customer, you feel bruised and distance yourself from the vendor. Eager to limit expenses and reach ROI, only absolutely critical bugs and features are given attention. The software works and is delivering value. Time passes.
The system works, so why bother spending money on it? You don’t need to spend money on it to keep seeing value. Minimal investments in bug fixes or feature enhancements occur. More time passes. The software becomes critical to your business. User interface trends evolve. Software libraries and packages used as the foundation of your system fall out of favor. The framework version your app uses reaches end of life. You start to find bugs, but they are only fixed by newer library versions. You are frustrated that the upgrade will be expensive. Users are frustrated because they must work around bugs.
Opinions of the app sink, and animus grows. Downright annoyed with your vendor, you start talking to a new development shop. They quickly validate your feelings of disdain for both the system and your previous vendor, and they push hard for a total rewrite. The pain of the last development effort has faded. You find yourself excited about the prospects of a shiny new system without the bugs or the baggage.
Stop the Cycle
Here’s what I’ve learned from decades of observing and participating in this cycle:
- If you spent $100K getting your app developed a decade ago, a rewrite is going to cost you at least that. Maybe even double.
- During initial implementation, there was no old system with bad data that needed to be migrated to your new system. This time, the migration of data could be a significant project all by itself.
- You are going to lose features. When you rewrite, your business will probably focus on the things that are appealing today. You’ll focus on today’s needs, and you’ll skip over some features from yesterday. You might not even remember these features. I’m constantly surprised how often clients need features that they assured me were unused.
- Your rewrite will go over budget. It will be late. You will feel bruised again.
How DOES this happen?
There are many reasons that software owners wind up in this cycle:
- Developers love a greenfield. We love creating from scratch. New projects are free of historical baggage and technical debt, therefore more pleasurable to work on. And, while developers typically don’t pitch rewrites for this reason alone, rewrites are lucrative.
- Once a project is completed and in production, many businesses cede to the temptation to turn off the money valve, and shut it tight. Everything is great for a while, but eventually code will atrophy. Dragging a system out of atrophy is expensive, and if you’re going to spend a ton of loot to get your system out of atrophy, why not just get a nice shiny new system, right?
- Businesses pay for rewrites, because to get value out of new software it must be built. Many won’t justify investing in current systems because they consider it an unnecessary cost . The irony here is these are the systems providing value, therefore it seems obvious that a business would be willing to invest in current systems. But the precedent is often set to not invest due to the bruising that occurs during and just after its initial implementation.
Budget for Software Maintenance
The fix? Budget for software maintenance and spend it. A good rule of thumb is 10% of your initial budget should be budgeted each year. If you spent $100k to build your software, expect to spend at least that again over ten years in upkeep and improvements. That small amount each year will produce tremendous benefits over the long run:
- Your business asset will not atrophy. You can keep your frameworks and dependencies up to date on a gradual basis. This is far cheaper and less disruptive than waiting several years and then making big jumps in software your application depends on.
- You can gradually keep up with changing standards in both usability and user interface.
- Bugs will get fixed incrementally, therefore users will be happier with your system.
- By consistently engaging with your development vendor they will understand your business. A developer that has an understanding of your business will speak your language and will be better able to ensure you continue to get value out of your software.
- There will be fewer disruptions to users or the business. Instead of a disruptive cutover, gradual improvements will reduce the need to train users to use the new system.
By budgeting for proper software maintenance, you will eliminate the need for, or even the attraction of, an expensive greenfield rewrite.
