When to rewrite a code base from scratch

Question

I think back to Joel Spolsky\'s article about never rewriting code from scratch. To sum up his argument: The code doesn\'t get rusty, and while it may not look pretty afte

Answer 1

The book Facts and Fallacies Of Software Engineering states this fact: "Modification of reused code is particularly error-prone. If more than 20 to 25 percent of a component is to be revised, it is more efficient and effective to rewrite it from scratch." The numbers come from some statistical studies performed on the subject. I think the numbers may vary due to the quality of the code base, so in your case, it seems to be more efficient and effective to rewrite it from scratch by taking this statement into account.

Answer 2

I would rather do things bit by bit, e.g., create a back-end to the database with a data model as you work in those areas (i.e., user login first, then user management, and so on), and tweak the existing front-end to use the new back-end (interface driven, so you can also add tests). This will keep the existing code with possible undocumented tweaks and behaviours that you wouldn't replicate by developing again from scratch, whilst adding in some separation of concerns.

After a while you will have migrated some 60% of the code base to use the new back-ends without the work being an official project, just maintenance, so you will be in a better position to argue for development time to do the other 40%, and once that is done the existing front-end classes will be vastly reduced in size and complexity. Once it is fully migrated, you will be able to reuse the new back-end model and controller components if you ever get the time to implement a new view.

Answer 3

I have been in precisely this situation but rather than a total rewrite I worked to change things through a refactoring process. The problem I ran into was the enormous complexity of the code I was working with- many pages of horrible, special-case-driven development all based on if-cases and convoluted regexes layered back over about ten years of unplanned growth and expansion.

My aim was to get it refactored function by function so that it would provide the same output for the same inputs but work much more cleanly and smoothly under the bonnet to facilitate future growth and improve performance. The general solution was clean and quick but the fixing job on the code just got more and more difficult and complicated as obscure special-cases in the documents being parsed by the system started to show themselves and my nice clean code would generate output that was just a little too different from what the original did ( this was web pages, so a different amount of whitespace could cause all kinds of layout problems on older IE versions ) in small and obscure ways.

I don't know if the reworked code ever got used- I left the company before it had the chance to be fully integrated- but I doubt it. Why use twenty lines of code when fifteen hundred 'if' statements and three-line regular expressions could do the same job?

Answer 4

Only one quasi-legitimate reason comes to mind: politics.

I've had to rewrite a codebase from scratch, and it had to do with politics. Basically, the previous coder who managed the codebase was too embarrassed to release the source code to the new team that had just been hired. She felt that every criticism of the code was a criticism of her as a person, and as a result, she only released code to the rest of us when she was forced. She is the only person with administrative access to the source repository, and whenever she's been asked to release all the source, she's threatened to quit and take all of her knowledge of the code and go home.

This codebase is over 15 years old, and has convolutions and contortions from various different people with various different styles. None of those styles apparently involved comments or specifications, at least, in the small portions she's released to us.

With only partial code available and a deadline, I was forced to do a total rewrite. I got yelled at as a result, because it was claimed that I caused a serious delay, but I just kept my head down and got it done rather than argue.

Politics can be a huge pain.

Answer 5

One danger in a complete rewrite is that your job is constantly on the line. You're a cost that isn't contributing to the bottom line. The code that sucks is the code that's making the money.

But if you fix the existing code one piece at a time, you're the guy who knows how the money machine works.

Answer 6

There's an old adage that says:

There's no such thing as bad code. There's only code that does what you want and code that doesn't.

The key to knowing when to re-write lies in there. Does the system currently does what you want? If the answer is yes, slow, but steady improvements are your best bet. If the answer is no, a re-write is what you want.

Going back to Joel's essay, he talks about code that's messy, but software that is reliable and delivers the expected value. If instead, you have unreliable code full of major bugs and that wasn't covering all your use cases. You had things that were supposed to be there yet don't work, or are just missing. In this case, all the little hairs growing out of it aren't bug fixes, but cancer.