The Big Rewrite
I've been hearing stories throughout my career of 'big rewrites' and how much better the universe is because of them. "We rewrote our java app in ruby and now it's 10x faster and 40% less Lines of code" and now "we rewrote our ruby app in node and now it's ...". When I was a scrappy ambitious young developer these sounded so attractive but also affirming. I happened to be starting doing Ruby full time and my response to quotes like the first was always "Of course! Ruby rulez!". Now being a little more mature and the leader of a team I realize that these stories are misleading and potentially harmful. They are the siren calls of an always forward facing programming community.
Starting Over
The biggest thing people seem to ignore about these stories is that, in many cases, much of the benefit of the rewrite was not from the new technology but from the fact that you started over. You were able to reexamine what was slow or obtuse about the current design and instead of having to move carefully to improve, you had a blank slate. Additionally you were able to pull from today's best practices and tools and use them holistically. If you did the same thing but used the same language or tech you would probably get most, if not all, of the same benefits.
What if you didn't have to start from scratch? Or probably more accurately, what if you couldn't? From my current position, my goals and success are judged by how much my team was able to improve the metrics of the company (revenue, new features, performance). From here it's pretty clear that a rewrite for the sake of pure performance is not inline with my goals. How long is the team going to not be improving the users current experience before the big rewrite is finished? Is the final product actually a large enough improvement to make up for the time sunk? I've seen this happen with my own eyes more time than I can count. We only ever really hear about success stories (you can bet there are a ton of failures out there) and even the successes leave this out of their accounting.
Middle Ground
When we want to do new big things at Paperless (everyone does) they have to fit a bunch of criteria:
- What are the long term benefits besides the immediate performance or readability gains? i.e. what will make it stay shiny?
- What problems does it solve that are not problems with just the implementation?
- Can it be done iteratively? Can we replace and improve in chunks instead of all at once?
- Are there external factors that require a change in tech? Ie is the current tech EOL or just a major security problem?
Within these criteria we are still able to accomplish huge improvements to our code base while still fitting within the goals of the organization at large. We've been working on a large rewrite of our existing create app in Canvas/JS - this has to happen as Flash is almost EOL, but also has allowed us to really do things that weren't possible with the previous tool. We're also very aware of the 'fresh start' aspect of this - doing it all again has allowed us to build a much cleaner set of tools.
Finding Balance
Obviously it's a balance with a very gray area. With a team of very ambitious young developers, there are strong desires to fall for the latest thing or scrap existing systems. This isn't out of the question, and we've done this in the right circumstances. However, we always try to approach this pragmatically. One thing I try to teach/preach is that there is always going to be yesterday's code and tools. Learning how to find the middle ground is one of the greatest skills a developer can acquire - it's something that I'm still working on.
Subscribe via RSS