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). I’m revisiting it for a presentation Rich Kilmer and I are doing this weekend at JRubyConf.

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:

Mel Riffe (@insanity_rocks)

when the mud (from big ball of mud) falls into your eyes

Mel Riffe (@insanity_rocks)

seriously, though, i believe when you lose confidence implementing changes it’s probably a good time to consider a rewrite

Jeremy Woertink (@jeremywoertink)

when you find yourself monkey patching areas that you wrote at 2am on a Saturday thinking “ugh, I just want this done with” :)

Justin Ko (@justinko)

the right time is after reading your infamous blog post.

Jay McG… (@hooligan495)

for us the big rewrite was: Scale fail (Can’t support more than 100000 titles) and customers want linux and not windows

Matt Freels (@mf)

almost never. Incremental rewrites of specific components results in better isolation and less risky code.

Rubem Azenha (@razenha)

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

Rubem Azenha (@razenha)

the bugs were all over the place, the chances were slow and risky and we needed to add tons of features.

Rubem Azenha (@razenha)

The CIO figured out that it would be more expensive to maintain the current product than to create a new one

Nolan (@sneakin)

when you’re singing “WTF! WTF! WTF! Holy Christ! WTF!”

Cătălin Tănăsescu (@catatk)

when you look at a code made by you and curse the programmer behind it

Jak Charlton (@JakCharlton)

when the pain starts to exceed the political pain required to get that kind of authority

krispy (@_krispy_)

– when you have enough in the bank to survive its possible failure to deliver on time and within budget

Aaron Patterson (@tenderlove)

When the fundamental design algorithm is O(n!)

Kirill Radzikhovskyy (@kirillrdy)

when you just can’t stand it anymore

Andrew France (@Odaeus)

About the same time you start asking that question :P

Thomas Fuchs (@thomasfuchs)

By having a ‘feeling’ about it. However, big software rewrites mostly fail. Better to start something new!

Jesus Jaquez Rueda (@JaquezRueda)

When you spend more time trying to understand code than writing code

danzon78 (@danzon78)

when only god know what are you trying to do

Mark Nijhof (@MarkNijhof)

wasn’t the answer “Never”?

BJ Clark (@RobotDeathSquad)

That’s a question searching for a rule that doesn’t/shouldn’t exist.

Celtic Wolf (@celticwolfinc)

, it’s time to do a big sw rewrite when adding small features/fixes requires a lot of time fixing/changing the existing code.

Eric Hodel (@drbrain)

I prefer never. I gradually employ targeted rewrites. The app will be eventually rewritten w/out the cost of stopping the world.

Cory Foy (@cory_foy)

When I sit around thinking, “Gee, how can I screw myself and bankrupt my company in one action?”

Jason Haruska (@haruska)

you’re netscape, you have crazy market share, your code smells, and Microsoft decides the internet is important. Oh, wait.

Celtic Wolf (@celticwolfinc)

, or when the cruft/ick factor in your code base causes good developers to quit.

Corey Donohoe (@atmos)

it’s rarely the right thing imho.

Jacob Tjoernholm (@chopmo)

I’d say when the creativity/crap ratio is about 1:10 and still declining.

Simon Harris (@haruki_zaemon)

I’ve never seen a good time to do it. Incremental change has always worked best, for me.

Brian Smith (@brianthecoder)

probably when you have to ask yourself that question + 1 week

Nick howard (@baroquebobcat)

When you haven’t written anything yet?

Sean Barton (@Seanba_)

When Code comments warn me that I couldn’t possibly understand what follows, and that it can’t be changed.

Lar Van Der Jagt (@supaspoida)

when the features you’d be trying to preserve by avoiding a rewrite never should have been written in the first place.

Cecilia Fernandes (@cecifernandes)

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.

Edward (Ted) Price (@priceted)

When the overly-sensitive head architect of the project leaves the co. because adding a form field becomes a herculean task.

Dan Tylenda-Emmons (@410formula)

when it is painful to make even a minor change

Fernando Troya (@ftroya_tech)

The more defects become stories with architectural impact the closer you are to that point!

Aaron Lee (@wwkeyboard)

you should divide and conquer; unless it’s a new paradigm in a new language.

Jeff Barczewski (@jeffbski)

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?

R.T. Lechow (@rtlechow)

@RobotDeathSquad BigRewriteQuestion does have a useful side effect: the earnest responses tell you “where that person is at”.

Scott Barron (@rubyist)

when someone ponies up the dollars for it

Mike Moore (@blowmage)

When your velocity is very, very low because of design and architectural problems in the code. Its a big hump though.

Tom Stuart (@morticed)

90% of the time it makes more sense to refactor the existing code. Unless it’s a ColdFusion app ;)

Andrew de Andrade (@andrewdeandrade)

It’s time for the big rewrite when the most experienced developer has lost all faith in the code base.

Andrew de Andrade (@andrewdeandrade)

However, before beginning a big rewrite, you need to “fix” the management responsible for a codebase that needs a big rewrite.

slainer68 (@slainer68)

> i do not wait for this moment, i try to refactor everytime :)

Andrew de Andrade (@andrewdeandrade)

Big rewrites only occur when both product and engineering management act “unprofessionally” per @unclebobmartin’s definition

Grant Blakeman (@gblakeman)

when i realize i’m spending more time compensating for existing code than writing new code.

Dan Tylenda-Emmons (@410formula)

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.

Steve Tooke (@tooky)

if the cost of adding value now is higher than rewriting and then adding value? I usually feel a rewrite is the scary option.

Jason Arhart (@jarhart)

When I start to consistently feel loathing rather than excitement when I think of better designs.

Andrew de Andrade (@andrewdeandrade)

@thomasfuchs I am pro-“abandon ship” as well. The need for big rewrites are signs of more sinister problems.

Matthew Kirk (@mjkirk)

We rewrote our app once when the original app was unbearable to maintain.

PJ Hagerty (@aspleenic)

For us it’s whenever the boss tells us to :) We converted an app from VFP 9 to #rails in just under 2 yrs

alexvollmer (@alexvollmer)

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.

Adolfo Sousa (@adolfosousa)

It’s time for the big rewrite when things are screwed-up or messy AND nobody is bikeshedding – in other words: never

Nathan L. Walls (@base10)

Secondly, if given the opportunity, I like walling in the existing app and building new apps around it to extend function.

Tara McLean (@TaraMclean)

I try to avoid big software rewrites as they tend to be a death march. Instead try to chip using a strangler application

Pablo Manrubia Díez (@pmanrubia)

When developers don’t look happy while coding. The less enjoyable it is for programmers the more rewrite is needed :)

Jim Garvin (@coderifous)

Must consider context, so right answer is “it depends”. But the raising of the question itself is probably an indicator.

Devdas Bhagat (@f3ew)

When maintaining the system in production gets too expensive (include running costs of hardware and admin time).

Roy Deal Simon (@RoyDealSimon)

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”