To rewrite or not to rewrite, that is the question
People seem to have given up completely on the notion of rewriting software. This is a shame since so much software needs rewritten, but it’s understandable since so many software rewrites fail. The decision on whether or not to rewrite is a complex one, and most companies will usually take the easy short-term path of attempting to fix the software in a piecemeal fashion. Unfortunately, this also fails most of the time, but at least companies don’t feel so bad about it since they usually end up only slightly worse off than when they started. Although I discussed this a bit in my “Fear of code” article, I decided go ahead and put together a more elaborate set of decision points on whether or not to rewrite a major piece of software.
Can it be rewritten in less than 2 months? If the answer is yes, you’re not within my definition of a “major piece of software”. Read on to help give you some perspective, but go ahead and rewrite if you think it will make your life a lot easier and treat the other rules with a grain of salt.
Do you honestly believe that if you rewrote it without adding any features the resulting code would be 33% smaller than the current code? If the answer is no, it’s not a candidate for a rewrite. Things are not so hopelessly wrong that they can’t be improved in-place. Things must be horribly bad before a complete rewrite is in order. Look for pieces of the code that can be rewritten (again looking for that magical 33% smaller boundary). Sometimes a piece of code makes every additional piece of code that much harder to write, but if the new code is dramatically harder to write then it’s probably getting badly bloated as a result. While there are kinds of complexity that do not create code bloat, these are the exception and not the rule and most of them can be dealt with via wrapping (hiding) the complex code in a layer.
The types of situations that require a full rewrite are the ones where a critical tool was used that was completely wrong for the job, or where key assumptions were made (possibly many of them) that later turned out wrong, or where complex business logic has become so hopelessly spread out through the edges of the application that every new feature requires massive cut and paste. If it feels like a project is hopelessly broken but you don’t see your rewritten version being 33% smaller then think harder about the WAY you would rewrite it and try to find a way to make it cleaner. Once you’ve found a way to drastically reduce the fat in the application you have understood the root cause of your problems well enough to justify a rewrite.
If you can envision doing away with half the code or more then you have an excellent candidate for a rewrite. Work hard to get the rest of the factors in line.
Can the code be done in less than 10 months? If the answer is no then you can’t do it. Almost no organization will keep a project alive for longer than about 10 months without seeing very strong evidence that it will succeed. If you believe it can be done in 10 months then it might take 16, but after 10 you’ll be close enough to get people believing. Notice I didn’t specify a team size, just a duration. You might be able to have a team of 20 working on a project for 10 months but you’ll never get a team of 2 for 100 months. One solution to this dilemma is to build a framework for the rewrite on a skunkworks basis in spare time or off hours. People only count the time from when they start investing in a project. You can also quietly bake some of this work in to the existing product so that some of the code will be in place and tested before the core reworking even gets discussed. Another solution is to think harder and find a way to get the value you need with less work.
Do you have a very senior sponsor who understands and believes in the project? If the answer is no then you can’t rewrite. There is no getting around this. I’ve tried. It can’t be done. You need a sponsor!
Can you get enough resources (even on a temporary basis) to support development on the old code base while the new code is written? If the answer is no you can’t rewrite. If the code is important enough to rewrite it’s important enough to need ongoing support. You can’t do both with the same people or the project will stretch to unacceptable lengths.
Is the project critically important to the company’s future? If the answer is no you can’t rewrite. Other projects will interject if this project is not vital. Large, nasty, but relatively unimportant software almost never gets rewritten. Of course larger companies consider MANY things critical to their future and are able to invest in rewriting them, but at some level people must believe the software is critical. It can’t just be an annoyance to developers.
Can the company go without a major release of the product for half the planned coding duration? If the answer is no you will probably (my first probably) fail. Even with parallel teams there will need to be a stoppage of major releases for a while as the new version gets shaken out.
Do you have anyone on the team who has successfully rewritten a major piece of software before? If the answer is no, get one or you can’t rewrite. Rewriting is not the same as other projects. It’s a specialized skill that balances design, code and testing with economics and politics. You need someone who has done it successfully before (even if they weren’t in charge).
This list is laughably oversimplified, but hopefully it gives you a few things to take in to account when considering a rewrite. How to rewrite is a topic I’ll leave for another day.
Reference: To rewrite or not to rewrite, that is the question
گزیده:
“When a defining moment comes along, you can do one of two things. Define the moment, or let the moment define you.”
– From Tin Cup
