When I'm coding at my peak, I'm removing more code than I'm adding. No, I'm not talking about  refactoring your code to be more terse or efficient. I'm talking about writing code to play around with ideas or flush out an example API, then getting rid of all of it if it doesn't pan out.

As I eluded to earlier, on the last application I worked on I found it much easier to start over from scratch multiple times rather than try to go back and fix the code. Sometimes the code was this bad because it had been written usually under bad assumptions or a bad understanding of the problem, and thus was fundamentally wrong. Other times I just found that even though the code was right and worked correctly, it just didn't feel right or was not as easy to work with as I would like. Regardless of how or why the code was wrong, it had to go, and I didn't think twice about deleting it.

I didn't necessarily scrap the entire application every time, but I would say between 10 and 15 times I scrapped large parts of the application, sometimes the entire application. Writing code is the easy part, but solving the problem in the right way is hard. You don't need solve every problem on your first try, and many times you won't, so feel free to start over and keep iterating until you solve the problem in a way that is acceptable to you.

Often, I would sketch out ideas on paper or try to figure things out in my head before trying to do the actual code. While in a lot of cases this was helpful, sometimes the solution I came up  just didn't work out as well in code as it had on paper. The only way to truly know how something will translate to code is by writing the code itself. This is similar to one of the primary benefits of test driven development, though I find this process useful even before writing tests.

Ultimately, the best reason to delete your code isn't about how pretty it is, how efficient it is, or how well commented it is. The best reason to delete your code is that you may not get another chance to rewrite it. You may find yourself stuck in a position where you are confined by the rules of your original code. As long as you are satisfied that you can live with those constraints, then sign off on that code and move on. Your code is your scratch pad, tear off sheets liberally until you are ready to paint.

You may have heard that rewriting an entire application is something you should never do. As usual, this is great advice 99% of the time.

Recently I was tasked with writing the new version of our payroll product and we as a team decided to write the product from scratch for the following reasons:

  • We were upgrading from classic asp to asp.net, so all of that code couldn't be shared anyway
  • There were serious performance problems with the existing system, so there likely wouldn't be much use in keeping the database related code.

After completing the rewrite, I realized the main reason it was successful was because the core domain knowledge about how things should work was still there, shared between 3 separate employees. When I started, I didn't know that much about how the product worked outside of what I knew from using it. I was given a sheet with the desired features, and some mock-ups of what the user interface would look like, and from there it was my job to figure the rest out.

I was able to ask the people who had written the prior versions (yes, more than one) whenever I didn't know why something was supposed to be a certain way when it did not make sense to me, or when I found the behavior of something to be ambiguous. I found that it didn't matter how I did something as long as the way I was doing it wasn't wrong. While that may sound stupidly obvious, acknowledging this fact can free you to make very radical decisions that may not have seemed obvious before.

Once you are no longer constrained by your preconceived ideas about how something should be done, you are then free to solve the problems like performance problems without sacrificing the features of the application or the integrity of the code.

So, was the rewrite worth it? Absolutely. The most important part of the system saw increased complexity due to new features while simultaneously seeing a 100x increase in performance. The only reason this was possible was by completely rewriting the program from scratch.

I should note, however, that rewriting an entire application is still incredibly hard. It's a lot of work and it takes a long time. It took me about 9 months to complete it and during that time I even rewrote the new code I had written about 15 times as well as I iterated and improved as I learned. A full rewrite definitely requires the right person or the right team to be successful.

Ultimately, I would say that it is OK (and perhaps advisable) to at least consider rewriting an application when there are significant complications to modifying the existing application, you still have enough of the core knowledge about the existing application at your company, and you have the time to pull off a rewrite. Even if you meet all the following criteria, a rewrite isn't always right, but it is worth considering.