Chad Fowler
A programmer, musician, and language addict.
Software developers: how do you know when it's the right time to do a big software rewrite?
Posted: Sep 30, 2010 8:49 AM
Advertisement
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:
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
@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”
Read: Software developers: how do you know when it's the right time to do a big software rewrite?
Previous Topic
Mel Riffe (@insanity_rocks)
Jeremy Woertink (@jeremywoertink)
Justin Ko (@justinko)
Jay McG… (@hooligan495)
Matt Freels (@mf)
Rubem Azenha (@razenha)
Nolan (@sneakin)
Cătălin Tănăsescu (@catatk)
Jak Charlton (@JakCharlton)
Scott Barron (@rubyist)
Mike Moore (@blowmage)
Tom Stuart (@morticed)
Andrew de Andrade (@andrewdeandrade)
slainer68 (@slainer68)
Grant Blakeman (@gblakeman)
Dan Tylenda-Emmons (@410formula)
Steve Tooke (@tooky)
Jason Arhart (@jarhart)
Matthew Kirk (@mjkirk)
PJ Hagerty (@aspleenic)
alexvollmer (@alexvollmer)
Adolfo Sousa (@adolfosousa)
Nathan L. Walls (@base10)
Tara McLean (@TaraMclean)
Pablo Manrubia DÃez (@pmanrubia)
Jim Garvin (@coderifous)
Devdas Bhagat (@f3ew)
Roy Deal Simon (@RoyDealSimon)