And even then, everything has to be so fucking abysmal that there’s no way to avoid it. The only time I’d ever condone a full rewrite is when you are completely abandoning an existing user base else you’re probably going to disappoint at least a good chunk of your users when everything goes horribly awry. Oh, “but it won’t go horribly awry because we’re such an amazing team” you say? Good luck with that, something always goes wrong and the larger (and/or older) the current codebase is the potential for problems goes up exponentially.
I’ve been through some major rewrites in my day, they generally are bug filled messes with obscure dependency issues from years of hacks and band aids and more gotchas than Thereza Bazar. Then comes the scope creep. I love shooting for the stars but sometimes, especially in a major rewrite, you need to shoot for “it works exactly like the old site did”. Obviously that doesn’t mean to bake in the same problems as before, but to the end user the basic functionality should remain unchanged to help make the transition easier. This is rarely the case and most rewrites include a full redesign of the front end (a/k/a hiding shit from your users) along with a rework of the backend and you end up with users that just want to cry.
How do I know that it makes users want to cry? Because I’m one of those users right now. DirectNIC (slowly losing ground as my domain registrar) recently pushed out a brand new site that looks a ton better but works about as well as HealthCare.gov. Fortunately their domain service hasn’t been affected by this but I can personally say that they’ve lost some money because of this new site. How do I know? Because I had to buy a new domain from GoDaddy recently because DirectNIC’s checkout was completely borked. At the time of this writing I’m unable to update the name servers on my domains which is proving to be a major inconvenience as I’m about 16 sites away from having all of my domains DNS using CloudFlare instead of Linode’s DNS (that’s for another post ;).
There’s a myriad of other non-mission critical issues going on but those two are my major pain points, not to mention how damn slow support has been to get back with me. I’ve been using DirectNIC for the last 10 years and this has made me seriously consider the major undertaking of migrating my (at the time of this writing) 56 domains elsewhere. In their defense, the new site does have two-factor authentication and I adore that new feature. The thing is, it was something that could have easily been tacked onto the existing site, probably sooner than this major rewrite which I assume was months in the making.
That brings me to my next point about all of this, a website is not a piece of off-the-shelf software and should never be versioned as such. Not every company needs to be deploying code hundreds of times a day but to put yourself into quarterly (or less frequent) releases is just the other end of extremes. Smaller projects are not only easier to manage but shorter development cycles help keep a developer’s head in the game. We all hit that wall of code fatigue from time to time and long projects that have no end in sight only perpetuates it. There’s nothing finer than pushing code and seeing your baby go off into the world, why would you want to deprive your developers of that satisfaction? Maybe orgasm denial is your thing, but seriously let your team release, that’s why you pay them.
But what about switching languages? I get it, you want to rewrite an entire system in some hot new botique language because the talent pool is better than the language you’re using (which is probably PHP if I had to guess ;). If you’re willing to switch languages you are also probably ready to gut your entire infrastructure as well. Instead of rebuilding a site from the ground up in the new language, why not move towards a service oriented architecture? If you were to apply this methology you could build any new components into the API and gradually rewrite the old language’s code into the new language’s API. This way, you are working in more maintainable chunks of development while chipping away at your goal. Once everything is ported over, you can swap out the core of the system for the new language all while having an API that’s been designed, built and tested in the new language.
I’ve applied this sort of logic to avoid larger projects because I really hate anything that takes me more than a few days to go from paper to shipping the code. It’s a little bit of extra work during the transitional period but you’re just paying it forward when you don’t deploy a month’s worth of code and have everything fall apart. Wouldn’t unit testing help avoid this? Oh yeah, but there’s still room for error in there (missing tests, tests that have always been broken, et cetera). Not just that but you probably want to rewrite your tests when switching languages. Nothing could possibly go wrong there, right?
Just some thoughts on ground up rewrites from a guy that’s pretty pissed off by a poorly executed one. Have you been through a major rewrite? Comment below with your horror stories and/or triumphs, I’d love to hear about them!
