Don’t rewrite code.

This is a story about Dave.

Dave just took his first Software Engineering job 4 months after graduating from college. He’s very eager to get going and to show his chops to the senior devs.

Dave’s first two weeks on the job after his introductory period are dedicated to bug duty. Bug duty is great for new hires because it lets them jump head first into many different facets of the codebase and learn how all the different subsystems communicate while also doing something productive: fixing issues!

On his first day after getting settled in Dave realizes the company’s bug tracking software is disgusting. It’s some old interface using UI elements so old that not only are they not flat, they’re not even rounded! It’s probably whatever must have existed before Web 2.0. Dave searches around the codebase and realizes that the subdomain for the bug tracker runs using Perl. What the hell?! How does anyone get anything done with this old thing?!

Clearly the best solution here is to make a new bug tracking interface that not only looks beautiful but uses a maintainable codebase. If it’s good enough Dave can even open source it and post his blog post about it on Hacker News. Perfect.

Instead of spending his first two weeks on the job fixing bugs, Dave decides to spend it on creating a new bug tracker. Obviously he ¬†also has to do the bare minimum bug fixing to make it seem like he’s working on what he’s supposed to be doing. During lunch his coworkers joke about how bad the old legacy systems are that Dave can’t even fix more than one minor bug a day.

After he finishes the MVP (minimum viable product) for his rewrite of the bug system, Dave excitedly sends the Heroku link for it to his supervisor, saying that that it’s something he was working on in passing and will definitely help quality of life at their company.

Dave assumes that Alice will be insanely excited. Not only did they get out of some crippling technical debt for free (I mean Perl, really?) his system also shows obvious work ethic, understandings of good the best paradigms, and the Flat-UI powered stylesheet makes it much nicer on the eyes than the old interface.

Alice replies with nothing but a link to the old system’s internal bug tracker. The link displays the first 100 historical tickets: bugs, feature requests, specifications and so on. Dave looks at it and realizes that every one of the bugs listed also exists in his system. Dave’s wasted two weeks of his life making half-functioning software that has the same issues the current system had 10 years ago.

His bug tracking system while beautiful and following Ruby coding conventions to a tee, doesn’t allow advanced searches. Or more than one-dimensional sorting. Or filtering by subproject. Or custom priority levels. Or…


When you do a complete rewrite without knowing everything about a system not only do you rewrite it, you also rewrite it’s first N bugs.

When you release a product into a competitive ecosystem, whether it’s a new video game fighting for control in an overpopulated genre or even just a new version of your own software, you’re not fighting with the initial release of the competitor.

Your product’s launch version needs to be as good as they are on whatever day they’re at now. This is the same reason every know MMO that comes out is compared to World of Warcraft as it is now instead of its first beta. This is the same reason why WP8 even though it’s in its relative infancy, gets its app ecosystem’s size compared to those of iOS and Android.

When competing with old versions of your own product you should never do a complete rewrite. Ever. If you’re the person that knows everything about the current codebase then you’ll be performing refactoring, which is completely different. Else you’re most likely just being over eager and refusing to deal with things other people have left behind. Decisions are made for a reason. You can’t just automatically assume that everything you’re dealing with was done out of pure ignorance.

If you are not the person who knows the entire system or if it’s so convoluted that no one does, you simply can’t rewrite it without breaking anything. First learn then refactor piece by piece.

This is a mistake I’ve seem at two person companies all the way up to enterprise software shops. There’s always going to be some Dave that refuses to work with an old or non-sexy codebase and for things even as simple as minor UI elements being drawn on a phone’ screen, I strongly believe that no code should be completely scrapped and rewritten unless the person who is doing it is aware of every single consideration that went into the creation of the original version.

If you’re at the point where you are aware of every decision that was made but you hate the end result, feel free to completely redo it all. It’ll feel great and should be pain-free. However if you’re unable to respond correctly to a question about a very rare edge case and how the code will react to it, you simply don’t know enough about the system to be able to safely rewrite it from scratch.

If you just spend your time rewriting everything you refuse to deal with you’ll never get anything done. Learning to deal with other people (both old co-workers and outside contributors) will allow you to develop at a much faster rate and actually focus on things that matter rather than the beauty of code or whatever the hot topic of the day is.