title: When to rewrite a code base from scratch
body: <p>I think back to Joel Spolsky's article about never rewriting code from scratch.  To sum up his argument:  The code doesn't get rusty, and while it may not look pretty after many maintenance releases, if it works, it works.  The end user doesn't care how pretty the code is.</p>
  
  <p>You can read the article here: <a href="http://www.joelonsoftware.com/articles/fog0000000069.html" rel="noreferrer">Things You Should Never Do</a></p>
  
  <p>I've recently taken over a project and after looking through their code, it's pretty awful.  I immediately thought of prototypes I had built before, and explicitly stated that it should not be used for any production environment.  But of course, people don't listen.</p>
  
  <p>The code is built as a website, has no separation of concerns, no unit testing, and code duplication everywhere. No Data layer, no real business logic, unless you count a bunch of classes in App_Code.</p>
  
  <p>I've made the recommendation to the stake holders that, while we should keep the existing code, and do bug fix releases, and some minor feature releases, we should start rewriting it immediately with Test Driven Development in mind and with clear separation of concerns.  I'm thinking of going the ASP.NET MVC route.</p>
  
  <p>My only concern is of course, the length of time it might take to rewrite from scratch.  It's not entirely complicated, pretty run of the mill web application with membership, etc..</p>
  
  <p>Have any of you come across a similar problem?  Any particular steps you took?</p>
  
  <p><strong>UPDATE:</strong></p>
  
  <p>So.. What did I end up deciding to do?  I took Matt's approach and decided to refactor many areas. </p>
  
  <ul>
  <li>Since App_Code was getting rather
  large and thus slowing down the build
  time, I removed many of the classes
  and converted them into a Class
  Library.</li>
  <li><p>I created a very simple Data Access
  Layer, which contained all of the ADO
  calls, and created a SqlHelper object
  to execute these calls.</p></li>
  <li><p>I implemented a cleaner logging<br>
  solution, which is much more concise.</p></li>
  </ul>
  
  <p>While I no longer work on this project [funding, politics, blah blah], I think it gave me some enormous insight into how bad some projects can be written, and steps one developer can take to make things a lot cleaner, readable and just flat out better with small, incremental steps over time.</p>