Rewrite or repair?

Question

I\'m sure you have all been there, you take on a project where there is a creaky old code base which is barely fit for purpose and you have to make the decision to either re

Answer 1

It is rare for a re-write of anything complex to succeed. It's tempting, but a low percentage strategy.

Get legacy code under unit tests and refactor it, and/or completely replace small portions of it incrementally when opportune.

Answer 2

It's not so black and white... it really depends on a lot of factors (the more important being "what does the person paying you want you to do")

Where I work we re-wrote a development framework, and on the other hand, we keep modifying some old systems that cannot be migrated (because of the client's technology and time restrictions). In this case, we try to mantain the coding style and sometimes you have to implement a lot of workarounds because of the way it was built

Answer 3

Depending on your situation, you might have another option: in-license third-party code.

I've consulted at a couple of companies where that would be the sensible choice, although seemingly "throwing away IP" can be a big barrier for management. At my current company, we seriously considered the viable option of using third-party code to replace our core framework, but that idea was ultimately rejected more for business reasons than technical reasons.

To directly answer your question, we finally chose to rewrite the legacy framework - a decision we didn't take lightly! 14 months on, we don't regret this choice at all. Just considering the time spent fixing bugs, our new framework has nearly paid for itself. On the negative side, it is not quite feature-complete yet so we are in the unenviable position of maintaining two separate frameworks in parallel until we can port the last of our "front-end" applications.

Answer 4

Repair, or more importantly, refactor. Both because Joel said so and also because, if it's your code, you've probably learned a ton more stuff since you touched this code last. If you wrote it in .NET 1.1, you can upgrade it to 3.5 SP1. You get to go in and purge all the old commented out code. You're 100x better as a developer now than when you first wrote this code.

The one exception I think is when the code uses really antiquated technologies - in which case you might be better served by writing a new version. If you're looking at some VB6 app with 10,000 lines of code with an Access database backend obviously set up by someone who didn't know much about how databases work (which could very well be you eight years ago) then you can probably pull off a quicker, C#/SQL-based solution in a fraction of the time and code.

Answer 5

One reason for rewriting at one of my previous jobs was an inability to find developers with enough experience to work on the original code base.

The decision was made to first clean up the underlying database structure, then rewrite in something that would make it easier to find full-time employees and/or contractors.

I haven't heard yet how it worked out :)

I think people have a tendency to go for rewrites because it seems more fun on the surface.

We get to rebuild from scratch!

We'll do it right this time!

etc.

Answer 6

There is a new book coming out, Brownfield Application Development in .NET by Baley and Belcham. The first chapter is free, and talks about these issues from a mostly platform agnostic perspective.