Sometimes Rewriting is the Only Option

Some time ago, I had the dubious fortune of having to work with a huge amount of legacy C# code. Mind you, the system was no more than a few years, yet it consisted of some one million lines of code. It was written by some outsourcing company, who (I later learned) got paid per line(!). Yes, that is true.

I did some statistics on the code base and found that 90% of the code lines were duplicates, copy-pasted from other parts of the system. In other words, only 10% were pure, pristine code. Not only that, but the code itself was a complete mess with no internal structure of any kind. Almost every method was static. Even the constants were defined in several places, with different values sometimes. The largest C# file consisted of twenty thousands lines, and on top of that, the system contained thousands of SQL stored procedures with an average of a thousand lines of SQL code each. The database structure held thousands of de-normalized tables and hundreds of "project" databases, each with identical schema. I'm not kidding.

It was the definition of big-ball-of-mud.

Needless to say, the system was extremely fragile, buggy and incredible slow. It could only handle a couple of simultaneous web users. The slightest change required editing maybe 20 files. It had already amassed some three thousand (known) bugs, although that was only the tip of the iceberg. It was a never ending minefield littered with barbed wires, failed attempts, wrong turns and skulking, raving mad, overworked programmers on the edge of giving up.

I have seen the system evil programmers have to maintain when they die, and it's not pretty...

I did my best explaining about technical debt and the importance of maintainable code. In my view, the system would eventually consume the entire company due to it being so costly to maintain. I argued with management about this and claimed we should rewrite rather then refactor. My standpoint was that it would be easier to re-create 10% of the code from scratch rather then spending the rest of our lives trying to eradicate 90%. It was no use. My pleas fell on deaf ears.

So we tried working around it using wrappers, strangling application, refactoring and adapters. The problem was that as soon as we tried to integrate with it, we failed because were not one single point of interaction, but thousands. We did pretty well transforming the company to something akin to agile thinking, but it was in vain since the system itself continued to fight us on every change.

I know there are lots of smart people who are arguing that it is less costly to user modern refactoring techniques rather than trying a big bang rewrite. I'm not saying these people are wrong, but there may come a time when one must accept the fact that some systems costs more to change than to rewrite. It's either that or desperately holding on until the entire business is lost in spiral of missed deadlines and lost customers.

On the other hand, I have been part of a very successful rewrite. But it did not happen until the company were on the very brink of giving up completely. Management simply had no other option.

Lets try a rewrite, we don't have much more to lose anyway and if things continue like this we are out of business anyway.

Any maybe that's what it takes. It's a bit sad it has to go that far, but there are some nice upsides to a rewrite, and in this specific case, the rewriting effort turned out to be a huge success for this company!

So rewriting might be a catalyst for something very good. You have a chance to rethink the systems positioning, a chance to add new features and new approaches which can help you target entirely new markets and customers. For instance, to change focus from feature-complete to ease-of-use or something like that.

After all, it's not the system that defines the company, it's the people and the sum of their experiences. Out of this mess something new and powerful might emerge, but it takes lots of courage and commitment to see it through.