There is a piece of advice in the software development world, which is pretty clearly expressed in this blog post by Joel Spolsky. It basically says that you should never rewrite your code from scratch.

I agree with this advice as a general rule to avoid running with the impulse of throwing out what you are working on sometimes, because you might feel like starting over fresh.

It could be when new technologies come around, making your legacy system look old-fashioned. It could be when you are sitting there at your job, frustrated and tired of shoveling code turds, trying to understand a legacy system that has had all sorts of bad design decisions implemented in it.

There can be many reasons why one might feel like starting over, because THIS TIME better decisions will be made, and everything will be better.

The reason why this is generally not such a great idea, is that you tend to forget how much work and hard-earned knowledge is actually baked into the systems we maintain. Sometimes, little bug fixes and unit tests of esoteric corner cases are the result of weeks of real-world testing and subsequent reproduction by developers, which is not so easily redone.

While the advice to avoid rewrites makes good sense most of the time, all rules come with exceptions!

At the other end of the scale we find something that is slowly becoming one of my favorite pet peeves: Software developers who go to great lengths to preserve code that they have already written, to avoid having to write it again.

Symptoms include having code repositories, directories of text files, GitHub Gists, maybe even OneNote projects, containing code snippets, which are then consulted or copy/pasted from whenever it is time to build something “new”. Other symptom is when “new” projects are started out by bringing in loads of code files of utilities, helpers, primitives, etc.

This type of developer might claim that it helps them “hit the ground running” – but my experience is, that it is more likely to make them HIT THE GROUND WITH A BACKPACK FULL OF BRICKS.

The thing is that this “new” project will not be built with new code or new techniques learned since the last time the developer worked on something greenfield – it will be built with all the OLD knowledge, the OLD techniques, and the OLD technologies.

When you avoid rewriting things by reusing your old code snippets, you are robbing yourself of a great self-improvement opportunity, because you don’t let yourself re-do something that you have already done before with the knowledge that you have accumulated since the last time you did it.

If, on the other hand, you take on rewriting things (often, if not) every time you build something new, even things like trivial CRUDdy coding tasks and other mundane endeavors can end up working like a form of code kata where each repetition can bring a new dimension or new refinements into the solution.

I should probably end this post by saying that I don’t think you should reinvent the wheel – or “invent the soup plate” as we say in Danish 😉 – every single time you need a wheel or a soup plate. Just be observant that you are not missing out on a great, new, improved soup plate, just because you thought that the one you got from your parents when you moved out at 19 was good enough.

PS: After having written this, I saw this post by Dennis Forbes, who seems to share my pet peeve, as he touches on that type of company that treats all of its homegrown code and libraries as an asset, when it is in fact a brick in the backpack. Read his post – it’s much better than mine 🙂

PPS: Inventing wheels and soup plates are terrible analogies to writing software. I will bet you almost anything that you can look at any piece of code you wrote a year ago and come up with several things you would do in a better way if you were to rewrite it. However, if this is not the case, I think you have another problem 🙂