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?

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?

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.

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)

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.

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...)

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 infoDose #37 (12th July - 19th July)

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

Perfect work!,