Yesterday I asked this question on twitter:
Software developers: how do you know when it's the right time to do a big software rewrite?
I've written about this topic before ("The Big Rewrite":http://chadfowler.com/blog/2006/12/27/the-big-rewrite). I'm revisiting it for a presentation "Rich Kilmer":http://infoether.com and I are doing this weekend at "JRubyConf":http://jrubyconf.com.
I got a bunch of replies. Some serious, some sarcastic, some obviously filtered through the jading effects of a few Big Rewrites played out. The answer ranged from "NEVER!" to "as soon as you feel like it's necessary". The one consistent theme is that software rewrites are scary and the decision shouldn't be taken lightly.
Drivers include maintenance cost, programmer happiness, politics, and fear.
Here's what the developers on Twitter said:
when the mud (from big ball of mud) falls into your eyes
seriously, though, i believe when you lose confidence implementing changes it's probably a good time to consider a rewrite
when you find yourself monkey patching areas that you wrote at 2am on a Saturday thinking "ugh, I just want this done with" :)
the right time is after reading your infamous blog post.
for us the big rewrite was: Scale fail (Can't support more than 100000 titles) and customers want linux and not windows
almost never. Incremental rewrites of specific components results in better isolation and less risky code.
My team did it once. The first dev team was gone, the code, design and database were a mess, there was no docs, no unit tests
the bugs were all over the place, the chances were slow and risky and we needed to add tons of features.
The CIO figured out that it would be more expensive to maintain the current product than to create a new one
when you're singing "WTF! WTF! WTF! Holy Christ! WTF!"
when you look at a code made by you and curse the programmer behind it
when the pain starts to exceed the political pain required to get that kind of authority
- when you have enough in the bank to survive its possible failure to deliver on time and within budget
When the fundamental design algorithm is O(n!)
when you just can't stand it anymore
About the same time you start asking that question :P
By having a 'feeling' about it. However, big software rewrites mostly fail. Better to start something new!
When you spend more time trying to understand code than writing code
when only god know what are you trying to do
wasn't the answer "Never"?
That's a question searching for a rule that doesn't/shouldn't exist.
, it's time to do a big sw rewrite when adding small features/fixes requires a lot of time fixing/changing the existing code.
I prefer never. I gradually employ targeted rewrites. The app will be eventually rewritten w/out the cost of stopping the world.
When I sit around thinking, "Gee, how can I screw myself *and* bankrupt my company in one action?"
you're netscape, you have crazy market share, your code smells, and Microsoft decides the internet is important. Oh, wait.
, or when the cruft/ick factor in your code base causes good developers to quit.
it's rarely the right thing imho.
I'd say when the creativity/crap ratio is about 1:10 and still declining.
I've never seen a good time to do it. Incremental change has always worked best, for me.
probably when you have to ask yourself that question + 1 week
When you haven't written anything yet?
When Code comments warn me that I couldn't possibly understand what follows, and that it can't be changed.
when the features you'd be trying to preserve by avoiding a rewrite never should have been written in the first place.
I guess we don't. But the turning point is usually when it gets too painful to keep it and too difficult/unstable to refactor.
When the overly-sensitive head architect of the project leaves the co. because adding a form field becomes a herculean task.
when it is painful to make even a minor change
The more defects become stories with architectural impact the closer you are to that point!
you should divide and conquer; unless it's a new paradigm in a new language.
I would suggest it depends on how well the project works currently and whether it can be done a piece at a time RT big rewrite?
@RobotDeathSquad BigRewriteQuestion does have a useful side effect: the earnest responses tell you "where that person is at".
when someone ponies up the dollars for it
When your velocity is very, very low because of design and architectural problems in the code. Its a big hump though.
90% of the time it makes more sense to refactor the existing code. Unless it's a ColdFusion app ;)
It's time for the big rewrite when the most experienced developer has lost all faith in the code base.
However, before beginning a big rewrite, you need to "fix" the management responsible for a codebase that needs a big rewrite.
> i do not wait for this moment, i try to refactor everytime :)
Big rewrites only occur when both product and engineering management act "unprofessionally" per @unclebobmartin's definition
when i realize i'm spending more time compensating for existing code than writing new code.
when everyone you ask says "oh that class? Yeah it's garbage. Nobody wants to touch it." Chances are, it's not the only one.
if the cost of adding value now is higher than rewriting and then adding value? I usually feel a rewrite is the scary option.
When I start to consistently feel loathing rather than excitement when I think of better designs.
@thomasfuchs I am pro-"abandon ship" as well. The need for big rewrites are signs of more sinister problems.
We rewrote our app once when the original app was unbearable to maintain.
For us it's whenever the boss tells us to :) We converted an app from VFP 9 to #rails in just under 2 yrs
That's the hardest question I've ever had to answer in this biz. You never know, you just guess and hope you're right.
It's time for the big rewrite when things are screwed-up or messy AND nobody is bikeshedding - in other words: never
Secondly, if given the opportunity, I like walling in the existing app and building new apps around it to extend function.
I try to avoid big software rewrites as they tend to be a death march. Instead try to chip using a strangler application
When developers don't look happy while coding. The less enjoyable it is for programmers the more rewrite is needed :)
Must consider context, so right answer is "it depends". But the raising of the question itself is probably an indicator.
When maintaining the system in production gets too expensive (include running costs of hardware and admin time).
a rewrite takes less time and has less risks involved than a functional conversion but results in lower quality as well.
by functional conversion I mean a rewrite-from-scratch scenario, and by "rewrite" I meant "refactoring"