Derik Whittaker

Syndication

News


Throw away and rebuild or refactor from within

The other day on Twitter there was a stream whether it is better to completely scrap an applications code base and start over, or refactor from within.  Now I do want to state right now:

The information here is based on my experiences and is simply my opinion.  I know this is almost on par with the average biblical debate so lets just agree to disagree now.

Anyway, now that I have put on the standard disclaimer lets continue on with the post.  As I stated there was a debate on which was better, rewrite or refactor…..

Once upon a time I thought that without a doubt that rewriting that crap filled, unmanageable and unextendable code was the ONLY way to succeed.  However, during my career I have come to the conclusion that rewriting was actually the wrong decision and refactor from within is the right one.  Here are some of my thoughts as to why

Re-Writing
Pros:

  • You get to scrap that old code that smells.
  • You get to build a better, more maintainable architecture going forward.
  • You get to use the latest technologies and this is always the best thing.
  • We know the business better now, this will allow us to create a better, more flexible application

Cons:

  • Is the business going to actually stop innovating or changing long enough to let you completly rewrite the application?  NO
  • If they are not going to stop moving forward this means there is going to be a maintance team doing this type of work.  This means you are coding against a moving set of requirements that will change daily… FAIL
  • What makes you think that you can write it better the second time around?  If you wrote unmaintable crap the first time why do you think you are better now (ok, assuming you did write it the first time). 
  • More than likely you are simply going to pile on the latest tech because you can.  Because you are an ego freak and the only way to write good code is to use new tech

Refactor from Within
Pros:

  • You have the ability to continue delivering new versions of the application with new features.
  • You actually increase your knowledge of what ‘crappy’ code looks like and how to fix it.
  • You can learn how to refactor your legacy code with minimal risk and learn how to do it a way that allows you to deliver new code

Cons:

  • This is NOT easy
  • This is NOT slow
  • There is always the thought that you will never actually be complete and that the refactor effort will be dropped at some point in the future.  If this is true, rest assured that your application will be better off anyway.

Ok, there you have it, my list of pros/cons for each (this is not an all encompassing list, just some of my random thoughts).  In my opinion the refactor is a better, safer choice.  But this is not as sexy and takes a ton more effort and patience.  However, I believe in the long run you will be better off.

Till next time,


Posted 07-13-2009 2:39 PM by Derik Whittaker
Filed under: ,

[Advertisement]

Comments

theparticleman wrote re: Throw away and rebuild or refactor from within
on 07-13-2009 5:25 PM

This post is a little troll-y too, but at least you gave a disclaimer this time.  Your RSS feed stays in Google Reader...for now.

I think the correct answer is the same correct answer as in most of software development: It Depends.  I think in many cases it makes sense to refactor existing code.  But I also think in many cases it makes sense to start over.

For my current work we've taken an approach that takes many of the benefits of both approaches and hopefully few of the drawbacks.  We have an existing framework for writing financial applications that people have been working on and using for the past 5 years with tons of applications already written using it (we're talking millions of lines of code.  Not the biggest thing ever, but considerable).  It has become such a big ball of mud that contains significant fundamental architectural problems.  This adversely affects application performance, initial development time and debugging.  Because of the huge architectural issues, we decided to start over.  But instead of scrapping everything and throwing away what probably amounts to hundreds of person-years, we decided to design a new framework that was separate from the existing one, but where the old one could still function.  This allowed us to have a fresh start, create a framework that fixes some of the fundamental flaws that the old one had, and even use some new technologies (if you can call unit testing and ORM frameworks new technologies).  The applications written using the old framework work just fine in our new framework (or at least they do so far).  New applications are written using the new framework.  Legacy applications that have significant problems can be re-written using the new framework, but legacy applications that are working okay can be left as is.

Doing this "Rewrite, but not completely" approach keeps us from simply throwing away code that (mostly) works and is giving our customers value.  But it also allows us the opportunity to repair the sins of the past (not ours.  The people who committed the original sins are long gone.  We're committing all new sins!) and provide a more stable framework for new development (a framework that can actually be unit tested and whose applications can be unit tested as well).

Any thoughts/comments on the dual-prong approach?

Derik Whittaker wrote re: Throw away and rebuild or refactor from within
on 07-13-2009 5:31 PM

@TheParticleMan

What you just described would be would be a refactor IMO.  You are taking a look at the app, you found failure points and you are working to resolve those.

Also, if this is troll-y then sorry, but I have to say you are DEAD WRONG.  The debate of scrap vs fix is always going one.  This is a conversation that must be had in a public forum and will help others to make a decision if they need to some day.

jdn wrote re: Throw away and rebuild or refactor from within
on 07-14-2009 12:01 AM

Of course this is troll-y.

No intelligent developer/architect/manager/whatever would make a decision on re-write vs. refactor without knowing the details of the application.  To make some sort of blanket statement without knowing that detail is incompetent.

Plus the 'Cons' you list for 're-write' are just silly.  You can re-write and add functionality.  In fact, this is the usual method.  If you can't re-write competently, what makes you think you can refactor competently?

Have you actually even been in a position to decide between re-writing or refactoring a real enterprise-level application?  Doesn't seem like it.

This is arguably dumber than your 'you should never put business logic in stored procedures' post, but in any event, it is dumb.  Were you drunk when you wrote it?

Mark Dalgarno wrote re: Throw away and rebuild or refactor from within
on 07-14-2009 5:12 AM

I cover this question when I run my 'When Good Architecture Goes Bad' workshop and of course the answer is it depends on the specific situation.

Rewriting is often pushed by developers keen to start afresh without the burden of having to support a legacy system and keen to update their resumes. But this may not be best for the business.

It often (usually?) happens that the 'rewrite' will turn into development of a new system - this is riskier than a straght rewrite and can delay delivery of a new product to the point that a competitor takes over and you're out of the game.

Reusing all or part of the legacy software within a new framework - as noted by theparticleman - can work well.  Reusing part of a legacy system depends on being able to identify 'good' parts of the current software and isolate them from bad parts - it's rarely the case that all of the code in a legacy system is bad. This can be tricky although there are lots of architecture analysis tools available to help in this task.

My limited personal experience leads me to argue that the decision to 'rewrite' is taken too often. I've seen several companies close or shrink significantly due to losses attibutable to failed 'rewrite' projects. I've yet to encounter a case where the refactoring approach has caused these problems.

To jdn

- unfortunately the rewriting cons are only too real and often ignored.

- refactoring incompetently is lower risk to the business than rewriting incompetently.

Jay Kimble wrote re: Throw away and rebuild or refactor from within
on 07-14-2009 8:53 AM

Dang! Give Derek a break! He lays out the pros and cons of each approach and does a good job.

he states his preference which is exactly mine, but yeah, it depends on your team, your app, and the business. Almost always (in my experience) the business doesn't want to slow down.. they want to keep pushing new features, so you have to balance delivering new features with getting the system fixed. It's called "ROI" or "Business Value" and it is why all of us are employed...

Where refactoring is never an option though is when you want/need to rewrite to a different language/platform (I'm currently rewriting a JSP app I wrote years ago and am replacing it with ASP.NET MVC.. no way for me to refactor that)

Christopher Bennage wrote re: Throw away and rebuild or refactor from within
on 07-14-2009 10:31 AM

It certainly is an ongoing debate. Here something Spolsky wrote in ancient times (2000!).

www.joelonsoftware.com/.../fog0000000069.html

He brings in a little history and sites one of the most specular failures of rewriting.

Derik Whittaker wrote re: Throw away and rebuild or refactor from within
on 07-14-2009 3:28 PM

@JDN,

Yes, have been in 2 places where this decision had to be made.  

In the first lets just say after 1 year, 4 million and failing the entire team was looking for employment.  

In the other after about a year we had not only delivered a few upgrades but we had also refactored a large chunk of the codebase.

Peter Ritchie wrote re: Throw away and rebuild or refactor from within
on 07-14-2009 3:31 PM

Well put, and good that you've come to the conclusion that refactoring is usually the best route.

One thing you didn't mention (and I find this is often the case of a code base worthy of scrapping and re-writing) is that requirements and features are only documented in the code; if you re-write it you often end-up changing the way the application works and annoying the end-users.  Re-factoring instead of re-writing allows you to notice these changes incrementally and compensate much better (like TDD, re-factor, acceptance, continue...)

Eric Nicholson wrote re: Throw away and rebuild or refactor from within
on 07-14-2009 9:01 PM

Under "Refactor from Within", shouldn't that be "This IS slow" instead of " NOT slow"?  I'm 4 years into refactoring a big codebase while it's in production and still have years left...  

#.think.in wrote #.think.in infoDose #37 (12th July - 19th July)
on 08-14-2009 2:55 AM

#.think.in infoDose #37 (12th July - 19th July)

Sevamma wrote re: Throw away and rebuild or refactor from within
on 10-10-2009 10:26 PM

I bookmarked this link. Thank you for good job!,

Nynadnry wrote re: Throw away and rebuild or refactor from within
on 10-12-2009 3:04 AM

Perfect work!,

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)