Before rewriting even an obviously badly written application, be sure that a) you’ll do it better (this time), b) there is a real ROI to do it and c) it is the best usage of your time.
You know them, I know them
Those applications are all too frequent to be missed. You stumble upon one or two at each company that you arrive, whether as a user (as a developer, it is difficult to not “snoop inside”, even when we know it would be bad) or (worse), as a maintainer. The most typical case is for me custom-made internal applications that probably solved a very simple problem once, a long time ago. They may have been a smart replacement for an Excel sheet becoming unusable (“oh, let me just one day, I could make something far better than that”).
This is not exactly one single application, more like a combination of some that I had the bad idea to find on my way, and that summarize for me the “bad application” case. This application is a web face-on-database, and was initially developed to solve a problem in a single service, which happens to be a part of IT. One of the reasons those things tend to appear in IT services is that those guys have (for better and for worse) the capacity to develop them themselves. If you are another service in a large company, the cost of the formal development demand would probably kill those infant-application long before the first line of code - which is sometime a very good thing.
Over the years, it did grow a bit, adding some features, and started to be used outside of the initial group. In the same time, following the organization changes, it did pass by half a dozen different hands, the initial sponsors (and developers) being long gone to other departments or companies.
Of course, you are not specially aware of all this history when you find yourself the brand new maintainer. What you will spot however is the technical nightmare. Among others, expect:
Outdated documentation - if any
Creative database engine (MS Access?)
Inconsistency all over the place (case, foreign key naming, plural usage, etc.)
Large unused parts (but which ones?)
A lots of web page with embedded SQL, and not a single line of reuse/import/include
Usage of very low level API (cookies, string manipulation)
At this point, it is just screaming “Rewrite !”, and your first report on the application shows a list of problems, and the benefits of rewriting it from scratch as soon as possible. Added bonus: it does not look so complicated, so it would probably not even cost much time.
Not so fast
I’ve been through there, you probably have too. The problem here is that technical debt, while being something too often underestimated, is not by itself an argument for rewriting an application from scratch. The two good questions, once the initial appraisal is done, are:
Will the new solution be much better ?
Maybe you think “Of course it will! We know exactly what it needs to do, and by starting over, we can have clean design allowing for evolution!”. You may be right, but you may also just have started a costly rewrite that could give birth to yet another bloated application. Doing better the second time is possible, but it is far from being automatic. In most situations, it will depends on the sheer size of the application (rewriting big applications is not easier than writing them - actually, as they are already running, it may be harder) and the availability of good information on what it is supposed to do (you do not want to rewrite based on the use cases that are in the code, and it is probably hard to read anyway).
The big rewrite scenario typically means choosing between rewriting the whole application before doing a “big bang” replacement or do it bit a bit, both alternatives being grim in their own way:
The big bang means a long period with the old and new application being maintained at the same time (each patch done on the production needs to be applied to the new system), without any new feature (which will not please the users). At the end, the deployment of the new system becomes something very complicated and risky, especially regarding the high expectation that the users will certainly have after having waited for so long.
The “replace the pieces” is a technical challenge in itself (make something new on the basis of something old is never simple) and the users will have to use parts of both applications during the whole rewrite period (losing whatever piece of consistency that may have been there). At the same time, each migrated component will require to be integrated in the blended system, and those successive operations will surely left traces even after the removal of the last part of the old system.
What is the ROI ?
As a developer, this is a question I got several times from my management, and that used to make me quite angry to justify, especially when the case was crystal clear (like, doing Unit Tests). Looking behind, not only do I understand the question, but I think it should probably have been asked more.
We are not doing software for the sheer sake of it (even if it may be enjoyable). We make software to make life (or business) easier. This doubly applies to rewriting, as your new application needs not only to work: it needs to work better enough to justify its added cost on a already running (and paid for) system!
The deciding rule should be the rewriting ROI, with indicators such as:
How many bugs are we getting on this each month? What time is spent fixing them?
How much is the application evolving? Do we get new features on a regular basis?
What is the mid-term plan for the application? Will it be replaced, stay there, or be used more and more?
Remember that for each point, having ROI in the new application is not enough: the difference between the current costs and the projected ones for the new application needs to be big enough (however good your new design may be, you’ll have bugs and code smells).
Finally, even if a ROI can be found, do not forget that one possible alternative to rewrite would be to buy an application to replace the old one. If the use cases are common enough, it probably does exist (every company and department thinks its needs are totally specific, and in most situations, they are wrong.).
My message and experience on this is not that we should never rewrite, but more that we need to make those kinds of choice with a product view, not a technical view. And this means in some situation to learn to live with the crapware that works good enough. It allows to concentrate on other, more important issues (that is: issues bringing more business value). Remember, development time (yours, your team’s, your company’s) is not an infinite resource: use it wisely.
Let them live, you have better things to do.