Full rewrites like this are a pain, high risk, and always take longer than expected (feature creep/deployment/etc)
This is accepted wisdom in large parts of the software development world, but I have become sceptical about treating it as a universal rule.
In the end, all software maintenance means rewriting part of the system at some scale, whether it’s a one-line bug fix or a Big Rewrite of the whole world. Both the risks and the potential benefits typically increase with the scale of the job, so how much of the system to change in one go is always a cost/benefit question.
All software maintenance where we delete or modify old code risks losing subtle bug fixes and behaviour tweaks that have accumulated in that code. However, it also gives us a chance to make the new code more systematic and to take into account additional knowledge gained and better tools that have become available since the older version was written. This means the new version also has an opportunity to eliminate subtle bugs and awkward edge cases that have accumulated in the old code.
For me, one of the times when a relatively large rewrite is indicated is when there are big changes to the foundations on which the system or some part of it is built: you need to support new hardware or run on a new operating system, there’s a big update to your programming language available and you want to be able to use it, the protocols or APIs or data models used to interact with other systems have changed. Another is when the original software architecture has been outgrown and technical debt is severely affecting productivity. In this case, it appears that both of those factors may apply, so maybe a wide-reaching update does make sense.
And with that in mind, I should clarify im not opposed to a complete gutting of a legacy codebase and I'm not afraid of doing it in a full rewrite sense of the word either. I just like to have a strategy and keep master green throughout.
> risks losing subtle bug fixes and behaviour tweaks that have accumulated in that code.
This shouldn't be happening in a sufficiently tested or sufficiently understood system and I feel like using it as an excuse to not rewrite is a lack of reasoning skills.
Full rewrites are a waste of time because you end up spending way more time than expected making useless decisions around the edges about APIs that really don't matter that much.
Or you end up finding out your dream design has a fatal flaw. Or you end up just porting a bunch of boiler plate.
Rule of thumb,
If you can't figure out a peicemeal way to refactor what you have into what you want you want, you have no business discussing what a rewrite should entail.
And a caveat to all this, I know a couple of teams that rewrite every system on a two year schedule. They do this as a a way to stay nimble. I believe their feature set and domain requirements are well known. This sort of setup has a few benefits and traits I like. Most notably the fact design skills are constantly being flexed instead of stagnating. Junior devs are made into seniors with this process.
It's all trade offs and just choosing when you want to make them. If adding 10k QPS load to your monolithic app is going to cost more than the (TOOLS + DEPLOYMENT STRATEGY + INTEGRATION TESTING + ETC) then it's worth pulling it out.
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
In particular, Basecamp successful rewrite seems more applicable here, since both are web services. They never sunset previous two versions though.
Edit: typo.
Getting to the point when you have to do a massive refactor is, in a way, a mark of success because it means you're growing and have a good customer base.
Acquiring tech debt in an early stage startup often results in never having to pay back that debt
Also... please people can we move off medium so I can stop getting spammy stuff about joining and etc? Clearly this person is a professional but at this point medium seems like using facebook to post a professional blog or something where this / that.
Sorry about Medium lol I'm just lazy. I plan to get around to hosting my own blog on Ghost.
It's one reason why people still use it.
That is to say they post because they want me to visit their business site ... not really tell me a story.
Now for any given user (the OP here) I wouldn't accuse them of that and I'm sure they'd like me to visit their site, but also want to genuinely share... but overall I start getting a different feeling from Medium posts...
Reminds me of when I was getting started with web development. SO MANY basics articles out there that I'm pretty sure are just resume fodder written by people who aren't that much better than me, and really not written to share as much as post on their resume, that really kinda sucks.
As someone who has spent the last year or so migrating consulting clients off of Rackspace services - I have to ask... Why Rackspace email?
GSuite: Best in class spam filtering. Mail clients are excellent. Integration with the rest of the Google ecosystem is wonderful. Google, as an auth provider, is fantastic. Downtime is nearly non-existent.
O365: Enterprise class mail tools, sub-par protection (spam and phishing will get through). Mail clients are fine. Even better if you're a Windows shop. O365, as an auth provider, is not as clean. Not as fault tolerant, but getting much better.
Solo entrepreneur full-rewrites are almost always churn inducing, feature stagnation, time sucks.
I'd advocate working on improvements to the current platform, one-by-one. Focus on features that increase your bottom line until you're at a MRR where losing 30% of your customers will be worth the cost of improvements.
Moving from Wordpress to Laravel means that the basic stack remains the same (PHP). All in all, this looks like something that ought to be possible without a rewrite.
I'd start with building a new front router that calls liberally into wordpress as a backend. Once wordpress is only managed (and accessible!) by the front router, one by one hack up wordpress to call into Laravel Spark stuff (eg. the user database) instead of using its own infrastructure. The end result would be that there's no wordpress code being used anymore (so drop it), and the site is completely moved over.
But that way every step in between won't be a regression to users, and it's realistic to add the odd emergency feature addition to the platform without having to maintain it twice (in the old platform and the new).
Please don't do that here. It breaks the site guidelines: https://news.ycombinator.com/newsguidelines.html
During the course of that I've isolated small sections of my project, and migrated them over a piece at time. Instead of perl "doing stuff" it now writes out data to JSON, and a golang service consumes that and does the actual back-end work.
This lets me rewrite the trickiest bits first, and also provides a level of isolation and abstraction I can test thoroughly.
Already I'm feeling much more productive, and I have more confidence that I don't need to install specific versions of gems (some ruby stuff too) and "unsupported" perl modules.
I am on the camp that big rewrites are more often than not a mistake. The real reason behind most rewrites is that writing code is easier than reading code. A system has grown to be too complex to understand, and instead of taking the time to study and understand it, you start writing it from scratch instead. At some point you end up with a new system of perhaps comparable complexity as the original. You now understand that system better, but give it enough time you will get rusty, or new devs will join that do not understand it. Rinse and repeat.
Also many devs underestimate the reasons why code has ended up being smelly. Unaccounted edge cases, legacy system support, time constraints. Who says you won't hit time constraints during the rewrite too?
Of course there are many good reasons for a rewrite too. Being more experienced and a better dev today than you were yesterday when you wrote it, is a great way to clean up whatever amateur mistakes you might have created. Or perhaps the system is inefficient and now you know how to improve it. But incremental updates, and defining the critical code path and making sure that is as robust as possible (eg I am sure you can increase system performance by magnitudes by changing only 10% of the most-often run code), are great ways to start.
Good luck, and I am looking forward lessons learnt too!
I believe a re-write should be a new product. New accounts will use it, and old ones will be migrated to it. Chances are, the way you did things the first time around wasn't ideal (but you couldn't have known back then), so the process is improving and not just the code.
This is similiar to refactoring, just at a larger scale.
We were able to purge unused features that had previously added complexity. Building a new app with 4yrs of knowledge from the previous app was enlightening. Now that we are through it, I feel the product is better for it, but damn it took too long.
Once all is settled, I ultimately tend to agree that I should've probably upgraded what I originally had, Ship of Theseus style. But then again, I also wasn't doing that, and the allure of a rewrite is what energized me to do all the work in the first place.
But I recognize this blog post as the sort of giddy excitement that you use to convince yourself that it's going to help your customers and be worth your time. Just look at it: all upsides, no downsides.
Tread carefully, OP.
I think this is really smart, assuming Rackspace does a good job of delivering mail. I don't think self-hosting email ever makes sense from a cost savings perspective.
What is you're time worth? A single hiccup and you've blown base $3 per month or heck $50 per month in cost savings.
I currently point the MX records of all my domains to my existing Fastmail account.
It just seems like a good example of an MVP. You got the site up in Wordpress fairly quickly, modified it using PHP to your liking (did you have to in order to implement features), and then some python to actually do some work on the back end?
Very unclear, but I think that would be of interest to this audience.
edit: Apparently the rest of his blog is dedicated to this info so in case you are reading this, are as curious as I was, and didn't think to click around:
Cheers!
