If you have an app that started life as a prototype or one that is starting to age – it may seem like cracks are starting to form here and there and it’s creaking slightly when the wind blows in a certain direction. The most common reaction from most businesses when their app starts to do this is to start planning a rebuild, but you have people using it already, which presents the question of how do you get these users onto the new system? What if I told you, no software, however old or broken, is a lost cause; it can be fixed!

Users’ expectations of software longevity has changed, largely because the way software is licensed has changed considerably in the last decade or so. From a periodic license which afforded you use of the software indefinitely with limited updates until the next (appropriately priced) shiny new version is released, to a model where you pay a monthly subscription that gets you use of the software, including updates, adding features and bug fixes. Herein lies your potential solution, apps that use the new update models, offer frequent and small changes to the benefit of both users and the business. You can iterate through your software fixing small chunks each time.

More often than not, new applications stem from a rapidly built proof of concept or prototype, leveraging technology that’s become more accessible to smaller businesses. This lets you deploy apps quickly and relatively cheaply, meaning that the first to release an app in an untapped market often has the monopoly for some time.

Unfortunately rapidly releasing an app often means it’s a prototype, which is fine to prove there is demand for your solution, but if you want the app to stand the test of time and a barrage of users, you need to ensure two things:

1. Your app will scale well, if and when it gets popular or goes viral
2. You’re mindful of any technical debt that may have built up

Technical debt is important, in short; it’s the tradeoff made during feature development to get the feature completed earlier, in exchange for a less than ideal solution to the issue. Reducing your time to market now is valuable but not free, those quick fixes won’t last forever, and the longer they’re left, the more time will be required to resolve them later . If you don’t actively work to reduce this debt, it will grow and eventually consume all your developers’ time. Software tends to age about as well as milk – it’ll go all lumpy and start to smell if left out for too long.

Look Before You Leap

There is a fair chance that at some point you’ve come across a project, so swamped with technical debt to the point where it doesn’t seem like saving. But before jumping to the conclusion that the solution is to start again (“it will be better the second time because we have all this hindsight”), consider what your users will do while you build a second version, and the level of effort required to get them to move to the new version.

As a business, if you have a (hopefully) mostly working application that your users are using to get things done, it is often worth the investment to spend time identifying where your application falls short in terms of functionality (like a search that badly matches based on phrases) and what areas desperately need some maintenance (such as the backup that runs in the middle of the day that grinds the system to a halt).

With that information in hand, you can make an informed decision about what parts of the system need repairing urgently – you may also have some recommendations from your developers/engineers. As with your users, don’t ignore this important insight, and get a risk assessment from them so you know what they’re recommending you fix and prioritise.

Your Software is Not a Lost Cause

Software is not immutable any more; it can be repaired – we have the technology! Software renovation is one of the things we specialise in, if you’ve got a software application that you’re feeling uneasy about – have a chat with us.

There will be parts of your system that work well, and because they do, you don’t even realise they’re there (squeaky wheel and all). These parts are key – they must be doing something right or your users wouldn’t be your users. Importantly, if you choose to rebuild, you’re throwing all of the working parts out as well.

Up front, without knowing exactly how bad things really are, fixing a system may seem scarier than just replacing it. I’m not saying it will be cheaper to fix than replace, but that it’s worth weighing up the cost of working with a new and potentially dysfunctional system for 6-12 months against seeing improvement in an existing one within 2-3 months.