Do you really need to rewrite your application?
Are you considering a rewrite of your bespoke application? Perhaps you are here because your developers are telling you that you should rewrite your application, but you’re sceptical? You’re right to be sceptical. There are times when it’s the right call. Most of the time it’s not.
The first question you should ask yourself is why you think it needs to be rewritten? Is the application or large parts of it just not working? Alternatively, are there parts that have rough edges or are causing you and your staff or users frustrations?
These scenarios rarely need to result in a complete rewrite. If the software is under five years old, the answer should almost certainly be “no”.
Now, if you think your software is working ok and it’s your developers telling you to consider rewriting it, that’s an entirely different question. What is their reasoning? Chances are it’s on one of these lines:
The code is a mess; there’s a considerable amount of technical debt, so it takes a lot longer than it should to develop new features or make changes, so it’ll be cheaper and better if we start again.
As developers ourselves we know it’s a continual struggle to balance client needs with the value that gained through the work. Unless it’s simple, obvious stuff then there’s always an unknowable factor involved because of the rate of change of all the interconnected parts which go into a working system. It’s quite easy for a bug in a library or some other outdated component three steps removed to cause hours of unexpected grief trying to track down the culprit and figure out a viable way to deal with it. Add tight timescales and budgets, and you have a recipe for disaster. Not immediately, of course, a quick kludge here and there seems fine. The problem is that it doesn’t get addressed. And then something similar happens again. If you’re paying your developer by the hour, the developer would be perfectly happy to spend hours making everything “perfect”. However, you want results, and it has to produce much more value than it costs to develop. Since development isn’t cheap, you do have to strike a balance and factor in the overall cost of maintenance to keep this kind of “bad” code to a reasonable minimum.
However, I would even go as far as to argue that if your developers weren’t communicating with you about this technical debt build-up, then they haven’t been doing their job correctly. And now they’re asking you to pay for their lack of foresight and communication. They are supposed to be the “experts”; you should not have to find out the reality this way.
To add to that, it’s unlikely it’ll be cheaper when you factor in your opportunity costs, etc. It is almost always better to incrementally refactor the existing code to improve it when new features are needed. Our mantra is little but often. It’s a small investment to continually be refactoring code which pays off in the longer term.
Related to #1, the old chestnut, “We know more now”
I would hope they do, but is it the same team that’ll be building the new version? If not, then they probably don’t know all that much more. The new team will make different mistakes. This is why it’ll still take almost as long to rewrite the whole thing as it took the first time to write it.
How long is the rewrite going to take to complete? You’ll have to use the old system for that amount of time at least, and it won’t get any improvements or be changed to meet business or market changes. The new version of the software will also probably need these new changes in too. Oh, and the developers will introduce new bugs. Some of the reason that the current code looks a bit crufty is that it contains bug fixes for odd scenarios that cropped up. The odds are good that these particular cases won’t make it over to the rewritten version.
“We picked the wrong platform”, or “there’s some new tech that’ll make things so much better”
Ah, developers and the latest shiny, new technology syndrome. Their hearts are in the right place; they got into this field because they like new technology, but too often they don’t consider the business ramifications of their desire to switch platforms.
There have to be some obvious, compelling reasons with a significant justified value if you’re considering rewriting a working application in new technology. Assume the rewrite will be a worst-case scenario of time and cost—is the value that could be created through the latest technology much higher than this? If it is, then go right ahead and get it rewritten. There’s a good chance this won’t be the case and add to that the fact that if it’s a brand new technology, then the developers won’t know it all that well, there’ll be hidden gotchas that will trip them up. If the new technology is still under heavy development, your developers are playing with fire. They’ll have to keep up with the development and the constant changes which might mean redoing parts of the application to use the latest version. To top it off, if it hasn’t yet got any significant traction with developers, another new shiny thing could come out that’ll kill it. We’re still seeing this today with all the hype about javascript libraries and frameworks. There’s still no clear consensus as to which might have any longevity.
We chose to specialise in Ruby on Rails. We kept an eye on it from the very early days playing with it internally because we could see its potential. However, we waited a full two years before we even started suggesting it as a viable option for client projects. Our conservatism has paid off for the long term. Rails is now a very mature and mainstream technology that is still more than capable and comparable to all the new tech. The advantage is that collectively we’ve had more than ten years to learn it’s foibles and squash bugs.
If you’re a startup, playing fast and loose and you have a short runway to get something out there to find traction it’s likely you don’t have a large application and the rewrite question is not such a big question. However, if you’re an established business with a critical business application that you and your clients rely on, then it is unlikely that you should take the risk.
We’ve been in this business a while, and we can say from first-hand experience that clients, like you, care far more about the stability, reliability and ability to change quickly than the tech-du-jour it’s developed in.
We have won the business of many clients simply due to them being sold a pipe-dream by their developers who couldn’t deliver on time or budget, or even a fully-working application.
At Foxsoft we don’t deal in the very latest “sexy” technology. We stay at the forefront of technology, but we don’t sell clients on it until we have proven it for ourselves. We work with clients who care more about what the technology can do for their business. This means using stable technology where the kinks have been worked out long ago. We have many clients using bespoke software which was written over 20 years ago that powers their daily business. There’s a good chance they could run for another ten to fifteen years. For them, it’s only now that they need to start considering whether a rewrite is the best choice for them. Note I said consider, not have to or should. Every business is different–there isn’t a one-size-fits-all answer. However, I’m willing to bet a rewrite shouldn’t be the first item on the list.
Still considering if a rewrite is right for you? If you want a second-opinion click the button below for an initial free, no-obligation chat to weigh up your options.
Book a free 20 minute consultation