The Big Rewrite

Thursday, January 27, 2011

Lego® 7685 - DozerUnlike refactoring, a "big code rewrite" bulldozes an entire application and starts over from scratch.

Is it ever the right thing to do?

In a recent post, Steve Blank says no - never for start ups in a fast moving market (Startup Suicide - Rewriting the Code):

CEO’s face the “rewrite” problem at least once in their tenure. If they’re an operating exec brought in to replace a founding technical CEO, then it looks like an easy decision – just listen to your engineering VP compare the schedule for a rewrite (short) against the schedule of adapting the old code to the new purpose (long.) In reality this is a fools choice. The engineering team may know the difficulty and problems adapting the old code, but has no idea what difficulties and problems it will face writing a new code base.

I think the big rewrite is almost always the wrong approach to "fixing" software - even outside of startups. Rewriting is a form of engineering wankery that makes it easy to avoid the hard work - identifying, prioritizing, isolating, and improving selected subsystems or components of an application while keeping the business running. This appears to be the approach Twitter took some time ago when the service was falling over each and every hour. See the "Improving Running Components at Twitter" presentation and note it's not called "Rewriting Everything".


Comments
gravatar nickd Thursday, January 27, 2011
So when is it OK? We have an eleven year old code base written in Delphi 5. Are we stuck here forever?
gravatar Al Thursday, January 27, 2011
@nickd

There are good discussions of this in "Domain Driven Design" and "Working Effectively with Legacy Code".

Working for ISVs and then as a consultant, I've been through a number a big rewrites, and I agree with Scott: it's almost never the best path. Instead, focus on an incremental upgrade and replacement strategy.

With your Delphi 5 system, you must have a way to make Remote Procedure Calls, even if just via REST. With that given, here's an approach I like:
1) Pick a small but important piece of the system -- maybe part where the most bugs are or the most feature requests are.
2) If possible, write tests against the existing code that verify all of the behaviors.
3) Re-implement that component in your new technology of choice.
4)Swap in the new component.

Yes, this will require continued investment in the old code to make it work with the new component. But it has many benefits including two giant ones:
1) You have significantly improved the situation in only a few months of work (i.e., a tiny fraction of the time to do a big rewrite)
2) You have a much better idea of how much work it will take to rewrite everything.

The strange thing I've noticed is that it's often easier to get funding for the big rewrite than for incremental improvement and replacement. There must be something in the human mind that craves starting over with a clean slate.

Good luck.
gravatar Rob Conery Thursday, January 27, 2011
Until you're in the thick of it - "in the sh**" as they say - it's a bit hard to understand the Great Rewrite. In other words - I think you have to wear 2 hats: business guy and coder guy (working for business guy). And when I say "guy" it's gender non-specific.

Anyway - I've rewritten Tekpub about 5 times. Granted it's not a HUGE app, but it's complicated enough. It had nothing to do with Wankery and everything to do with refinement. This is going to sound weird, but I figured that by refining/stripping/simplifying to where we are now has really helped. James is in the code a lot more (cause it's no a mess) and I'm able to push changes much easier than before.

Which is really the name of the game: flexibility. If we're talking specifically about startups - you need to spin on a dime. You can't do that if you don't allow yourself to start over. Moreover you can't do that if you use tools that are cumbersome and long-winded. It's why we went with Rails/Ruby over .NET.

Not saying that you can't do this kind of thing in .NET. I happen to be quite fast with it - it's all the other stuff: deployment, hosting, etc. I'm not trying to go on a bender over platforms - BUT when you look at this discussion in light of tooling and support it becomes trivial.

My whole point is that you *should not fear* the rewrite. You should plan for it - it's going to happen so embrace it. You will grow your idea and customers will demand something which will make you change your architecture. Eventually you get to the Tipping Point and you either give Frankenstein another arm, or you rebuild and embrace it.


gravatar Jeff Thursday, January 27, 2011
I partially agree with this. I think it is the wrong thing to do maybe half the time depending on where you are I guess. But I work for a corporate manufacturing entity that has many internal legacy applications that really not much can be done with. The code and the architectures are brittle, and any attempt to extend functionality is expensive and bug prone. I mean they really suck. In these cases, the refactor is as expensive as the rewrite, but at least with the rewrite you end up with a product that is cheaper to extend.

Of course all this depends on the depth of the proposed change(s) to the legacy system.
gravatar KevDog Thursday, January 27, 2011
If you sucked when you wrote the original, you will probably suck when you do the rewrite.

Another way of saying the same thing is that if you can't clearly elucidate the problems with the existing code base (without using terms like, "Module X sucks"), you won't be in a much better place when you do the rewrite.

gravatar Rob Conery Thursday, January 27, 2011
@KevDog using that logic then you "sucked" when you first learned to walk, and the next time you tried it you sucked again. And likely every time you've walk after that you've continued sucking. If you couldn't figure out how to run then - how can you possibly figure it out now?

If you sucked asking that girl out then you'll probably suck asking the out the next girl.
Perhaps you really sucked at Math - good thing you never tried it again.
If you suck writing Hello World in VBScript - what makes you think you'll be able to write it in C#?
If you suck at sucking... then... shit now I'm all twisted up....

Another way of not saying the same thing is that some problems don't exist when you start writing the application - especially with respect to Startups. If you think you can solve all of your problems up front - you should stay in the cubicle.
gravatar Paul cowan Friday, January 28, 2011
I don't think there is ever a binary decision of good vs. evil.

Expressions like never, don't and always are wide of the mark.

Nothing should and nothing can be brought down to a never or don't ideal....well, apart from this sentence maybe :-).
gravatar Glenn Friday, January 28, 2011
Java is dead around here. One of the primary reasons is that it was tied to WebLogic and Oracle which creates an enormous start up cost for new clients.

In order to capture the long tail of clients, we have to get our costs down. That precipitated a decision to rewrite the software in .NET using WPF. We're doing it a module at a time.

A journey of a thousand miles...
gravatar Jeff Friday, January 28, 2011
I agree that a total rewrite, up in lights, is usually the wrong thing to do. That said, the concept of a total rewrite shouldn't be vilified.

Incremental rewrites make everyone feel better, and is what I personally prefer. Minimizes risk and allows for incorporation of new ideas that are learned as you try to emulate what the to-be-rewritten app does.
gravatar Wayne Molina Friday, January 28, 2011
I disagree with this completely. When an application has just been pounded out with neither rhyme nor reason and hasn't used any proper software engineering concepts because either the team didn't understand them or there was no time, you cannot just refactor the code or "make remote procedure calls"; there will come a time when you can no longer bolt on new things to the existing app but MUST take the time to build it properly.

This is doubly true when the business' vision has changed over time - the absolute wrong thing to do is keep stacking up a veritable house of cards out of fear of taking the time to do things the right way from scratch utilizing what you've learned.

Call me cynical or jaded or whatever but I've worked with far too many "legacy" apps that were piles of garbage and had grown so big that the company, and more importantly the developers, were stuck wading through the sewage daily because nobody would take the time to bulldoze the thing and do it right.
gravatar Dominic Cronin Saturday, January 29, 2011
Start-up code is quite likely to be a dreadful hack in order to get to market on time. The first architecture is likely to be wrong, and if, for example, it won't scale to the scenarios needed by expected business, then a re-write has got a lot to be said for it. I once worked for a company that did this a couple of times - once to change platform, and later to give significant gains in performance and maintainability. (I was on the team that did the second rewrite). At other times they relied on evolutionary approaches. I'm talking about a company that survived its growing pains and is now well respected in its sector.
gravatar Cole Shelton Sunday, January 30, 2011
I agree with @Wayne. We are in the middle of rewriting a codebase for a client because the time it was taking us to deploy to their new clients (they sell the software and customize for each) was about half the time it would take us to rewrite. The code was about 5 times as large as it needed to be and was written by a guy just out of college. It was pretty miserable. After we are done, they will be able to deploy much faster and have aggressive growth plans. Also, good developers hate working on bad code, sooner or later they will just pack up and leave.
gravatar Jon Rimmer Monday, January 31, 2011
Why are so many discussions on coding and software engineering predicated on viewpoints that reject nuance in favour of some extreme 'never do this' or 'always do that'?

We get statements like 'apply the rule of demeter!', 'goto considered harmful!', 'never rewrite, always refactor!' repeated dogmatically by developers who usually have no real evidence to back them up. Whatever their original basis, they become received opinions, passed between peers with no knowledge of their original context.

Or sometimes they are a result of a personal experience where a project failed and a developer decided the blame laid with some particular choice of technology, process or idiom. Often the supposedly guilty factor will be something the developer dislikes on emotional grounds. Asked to develop a new application in Java and the project overruns? Clearly Java sucks, and if Python had been used instead things would have been fine.

In truth, received opinions and personal, anecdotal evidence are no proof of anything. Software development is too complex a process, and people's viewpoints too subjective and biased, to draw black and white conclusions about best practices. In a perfect world they would suggest hypothesises that could be tested in a controlled fashion.

Obviously this kind of scientific testing of everything isn't really possible (although it's definitely something that could be done more), and decisions have to be made with limited evidence. Developers should recognise that every situation is different, and needs to be considered by its unique circumstances. Personal experience and the opinion of peers should certainly be considered, but never taken as gospel.

The ability to analyse in this way, and make consequent correct decisions, is what makes someone a good software engineer. It may come naturally, or it may develop over a career, but it is not something that can be short-cut in the form of glib statements about doing or not doing certain things.
gravatar Scott Allen Monday, January 31, 2011
Just for the record, I did say "almost always the wrong thing to do", which doesn't mean "never". I'm not talking about the "build your own blog I cranked this out in 7 days" type application. I'm talking about the applications with millions of dollars and several developer-years of investment involved. Working applications that are thrown away because a team doesn't like the codebase or wants to flirt with the latest whizz bang object relational mapping framework that a vendor promises will deliver huge productivity gains.
gravatar Al Tuesday, February 1, 2011
@Wayne

You seem to think I'm advocating bolting on more crap to the big ball of mud; if so, I wasn't clear.

My point is that it's usually better to carve out small pieces of existing crap and replace them, one by one in a methodical pragmatic way. Obviously, you would still write the new pieces "the right way from scratch utilizing what you've learned."

As Scott says, the big rewrite is not about rewriting your blog software. It's about replacing big, complicated systems that have a multitude of integration points. Too often arrogant developers think they can completely rewrite a system in year, even though it took 10 years of development to build the original system.

Don't mistake me: I totally agree that rewriting is often necessary. I just prefer the Agile rewrite over the big rewrite. It's usually safer and more successful, and it puts working software in users hands more quickly.
gravatar Nicholas Carey Thursday, February 3, 2011
Re-implementation is often faster than torquing the current stuff to fit due to the fact that building the first one was a "learn-as-you-go" experience. You understand the pitfalls and know where you could could have done better.

To quote Fred Brooks' classic _The Mythical Man-Month_, "The question, therefore, is not whether to build a pilot system and throw it away. You will do that. The question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers."

The problem with most software is that the throwaway was delivered to the customers.
Comments are now closed.
by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!