On Rewriting Code

Are rewrites good or evil?

It all depends on who you ask or what blog post you read.

I read Jeff Atwood's post on the topic of rewriting code this morning and felt that I must opine. I agree wholeheartedly with many of his takes on the topic and especially love his final statement:

If you want to know how the application really works, run it and see what happens. Then go write your own version.

The debate centers around whether the best way to understand code is to read the code or rewrite it. To rewrite it, at least in my humble opinion, means that one must at least understand what the requirements are of the application (e.g. what should the application do when this button is pushed? etc.).

In my experience, I have found that it is a rare circumstance where rewriting an older application can and will yield stronger, better, more robust code, very much in the same way that rewriting an article or manuscript gets better as one rewrites.

In fact, sometimes the code doesn't even have to be that old. There have been a few cases where I have lost 100s if not 1000s of lines of code that I had been writing (lesson learned a long time ago about frequent and steady use of source control) and lost and was forced to start over from scratch.

After taking a half day or so to recover emotionally, I essentially rewrote and each time yielded a stronger code base because I had already been through the solving of many of the problems already and was able to do things like apply different design patterns on the fly (in a since, by this time I was refactoring).

I do believe, however, there is much to be gained by reading through code, and lots of it. I think to improve at writing good code, you have to do both, read a ton of code _and _write a ton of code. They go hand in hand.

Tags: writing code, programming, software, development, rewriting, code rewrite