Don’t rewrite Your Application
When stuck with a legacy code base you’ll hear the claim “We’ll have to rewrite this from scratch in order to fix it!” It sounds promising. You start with a clean slate. You can do all the good stuff without all the mistakes. The only problem: It doesn’t work. Here is why.
- What every you might think of the code base and the developers that created it: They weren’t stupid nor evil. So chances are the results of your work will look just as ugly in two years from now.
- You don’t know the requirements: Part of the reason legacy code bases are ugly is that requirements change. There is no reason for you to assume this won’t stop.So chances are the results of your work will look just as ugly in two years from now.
- You don’t have the time: As long as the rewrite isn’t done, you’ll need to maintain and probably evolve the current application. If it is of any importance, you can’t ignore it for the months to come. If you can you should do so without wasting your time with a rewrite.
Instead of rewriting the application refactor it. Learn to properly estimate the effort needed for implementing new features in a clean way. Add some time to make the code immediately around that new feature a little cleaner as well. Use that as estimate. This way the application will become a little cleaner with every update. Nobody needs to spend a huge lump of money without a good chance on a reasonable ROI. Instead you spend a little money and get what you paid for. The interesting effect of this approach is: The part of the code changed often will become cleaner fast. And nobody should be concerned to much with code that doesn’t change anyway.
If you can’t implement new features in a clean way I claim: You aren’t really able to implement the whole application in a clean way from scratch either.
There are only a few cases in which I’m willing to believe a rewrite is benefical:
- Change of basis technology: Is the legacy code written in Cobol and you will loose the last machine running that? Is it a rich client and it must become an internet application? You might not have a choice.
- Change of scope: Is 80% of code not needed anymore due to some changes in requirements? And you have to implement just as much for new features? You are doing a rewrite anyway.
- Tiny application: When the rewrite is done end of the week, I guess it is Ok to do it. But I still recommend doing it using refactorings. It will teach you the technique for the next larger legacy application.
- Somebody is willing to pay for the rewrite, but not for the effort needed to keep new code clean. It sounds extremely stupid to me, but I was told this happens …
What happens if the developer was an idiot and wrote the app is a completely backwards way? Then was maintained by someone who was skilled enough?
I am facing a similar situation at work, the code is shockingly out dated, there is no sign of any structure and doesn’t following a logical flow…
Its like its been a collapsing building being held up by duct tape.
So i kinda disagree…
Not at all. If you have some running code, it’s better to give variables and methods better names, reduce code dupes and see then, if you get the code’s sense. After that you decide what to do next (see http://www.sigs-datacom.de/fachzeitschriften/objektspektrum/archiv/artikelansicht.html?tx_mwjournals_pi1pointer=0&tx_mwjournals_pi1mode=1&tx_mwjournals_pi1showUid=6635)
I rather disagree with this. If you have a significant software product it has probably been reworked many times over a great many years before you come to the point that you will consider to re-write it. In such a case, technology has always changed since the original implementation.
Refactoring legacy code has all the stumbling blocks that re-writing has – if you want to make sweeping architectural changes, you have to really understand what it is suppose to be doing (e.g the product specification + all the extension hacks). If you don’t have a deep understanding of the legacy code it is pure folly to attempt deep structural changes.
I make the point that when we have considered re-writing a software product they were typically more than 10 years old with as many years devoted to heterogeneous development (i.e. some extensions are better than others). It is rare that over this time your platform and development environment will not have changed.
Additionally re-writing also means re-considering the specification and lessons learned over the life of a product – which typically can only be realized if we bring the entire application in question rather than just trying to clean up the code so it doesn’t fall apart for another year.
I don’t agree with the article. If the application design sucks (because of stupid developers, which is a really common scenario), refactoring would be a hell. In many cases I would prefer rewriting the application.
[...] Don’t rewrite Your Application Schauderhaft (tags: programming) [...]
I agree with the article. To offen rewriting is just the easiest way to start something new and comfortable. But it is only easy at the start. Later you have to learn the hard way, what your old application all did, but nobody knew. If you do not know the old app/functionallity you will have a hard time completing your product. And all product owners I know do not easily decide to kick some requirements out, but rather come up with some new additional stuff they always wanted to have. And you will promies them, as I did
, that all that can be implemented much faster, if you just get permission to rewrite it all. I failed to often with that. Why? There is to much work left, at the end of the time budget you are allowed to spend. You will get a lot of pressure, or worse, your business will not survive it.
If you really try hard, there are often ways to change some things in the legacy stuff to improve it a lot.
Here I like something I read from Marty Abbot: If you can not find a way to refactor your app, fire your architects.
I agree with OliSchmitz, rewriting might seem an easy way out but it wont. You need have a deep understanding of the legacy code. And your newly rewritten code will only be as good as the time you’ve written and would look stupid 3-5 years from it. I would prefer cleaning up the house with refactoring and making each of its modules more maintainable and more easier to support is more likable than spending so much time building a new code base.
I wrote a post a while-ago entitled Re-writing is cheaper than refactoring legacy code, What I actually advocated some would consider refactoring but I consider it re-writing, is to cut modules out of the legacy code base and re-write them. Putting tests around where you perform your removal in order to be able to test your new code transplant when it’s hooked up.
The problem I’ve found with legacy code is
1) No tests
2) No surviving requirements docs
3) No living person that understands what it’s supposed to do
4) It’s so hard and slow to add features it’s just painful
In general I really agree to that and also think this is the better way to do it.
But what if you need/ want to refactor like to core library/API on which like all the other stuff depends on?
How can you do a clean refactoring here without touching everything at the same time (complete rewrite)?
If you have a substantial library on which ‘everything’ depends and you need to refactor that, you obviously have a problem.
The approach to use normally looks like this:
- if not already present, create a thin layer between the existing library and its client code.
- implement a little piece of the new library.
- switch in the separation layer to the new library for this small set of functionality.
- remove obsolete pieces of the old library.
- rinse and repeat.
Is it easy or fast? Neither. Is it way more secure than a rewrite? Certainly!
A substantial library on which ‘everything’ depends is in this concrete case the JPA part if a JEE project. Database design in the first place and also persistence entities are a nightmare. Unfortunately, these persistence EJB are also DTOs which travel through the complete application.
If the system is consequential then a re-write may not be an option that one can take, no matter how bad the codebase may seem.
I can recommend Michael Feathers’ book “Working Effectively with Legacy Code” for offering useful techniques for dealing with legacy code.
Improving bad code, implementing tests and creating documentation can be an intellectual challenge every bit as stimulating as a greenfield project.
[...] за что в конце рабочего был награжден ссылкой на статью, в которой приводятся веские и разумные аргументы [...]
Evolution implies dying.
Neverdying code becames living shit.
@notus You are right, eventually every application will reach its end of life and will die. It might even get replaced by a different application. But hopefully it won’t be a rewrite but something different, something new.
Of course the line is blurry.
@Jens I’d this sad experience.
A very good system was born, caught a wide market(still takes one) then was sold to …,
then stops self development
(just stupid refactoring, refactoring..).
Now, indian supporters accompanies “her” to dying.
She was not rewritten right time.
Eric Evans has similar ideas (. His idea is to create a platform on top of the lagecy application. On this platform you can write your new shiny, tested code. You use an anticorruption layer to avoid that the legacy code will leek in your new code. And if you follow Martin Fowler you can apply event interception and asset capture to move the core functionalities away from the legacy code (. At the end it is all about risks.
[...] I’m probably the last to find this excellent piece on Jens Schauder’s Blog called Don’t Rewrite Your Application. It’s not only worth reading, but also thinking about it and memroizing it. There’s [...]