Often the problem with companies running the Feature Factory production treadmill too long is you have code supporting unused features and business logic, but nobody knows any more which features can be dropped or simplified (particularly after lots of employee churn and lack of documentation). So the problem is not so much technical debt, but product debt.
You can refactor, but you're also wasting time optimizing code you don't need. A better approach is to sit down with rest of the company and start cutting away the bloat, and then refactor what's left.
I was involved with a big rewrite. Our manager had on his desk the old system with a sign "[managers name]'s product owner". Nearly every time someone wanted to know how to do something the answer was load that old thing up and figure out what it did.
Eventually we did retire the old system - while the new code base is much cleaner I'm convinced it would have been cheaper to just clean that code up in place. It still wouldn't be as clean as the current is - but the current as been around long enough to get some cruft of its own. Much of the old cruft was in places nobody really touched anymore anyway so there was no reason to care.
> while the new code base is much cleaner I'm convinced it would have been cheaper to just clean that code up in place
I saw one big rewrite from scratch. It was a multi-year disaster, but ended up working.
I was also told about an earlier big rewrite of a similar codebase which was a multi-year disaster that was eventually thrown away completely.
I did see one big rewrite that was successful, but in this case the new codebase very intentionally only supported a small subset of the original feature set, which wasn't huge to begin with.
All of this to say that I agree with you: starting from scratch is often tempting, but rarely smooth. If refactoring in place sounds challenging, you need to internalize that a full rewrite will be a few times harder, even if it doesn't look that way.
I stayed at a place that was decades old, in part to decipher how they’d managed to get away with not only terrible engineering discipline but two rewrites without going out of business. I figured it would be good for me to stick around at a place that was defying my predictions for once instead of fleeing at the first signs of smoke. I’ve hired onto places that failed before my old employer did at least twice and I feel a bit silly about that.
I wasted a lot of my time and came away barely the wiser, because the company is spiraling and has been for a while. Near as I can figure, the secret sauce was entirely outside of engineering. If I had to guess, they used to have amazing salespeople and whoever was responsible for that fact eventually left, and their replacement’s replacement couldn’t deliver. Last I heard they got bought by a competitor, and I wonder how much of my code is still serving customers.
> I saw one big rewrite from scratch. It was a multi-year disaster, but ended up working.
90% of large software system replacements/rewrites are disasters. The size and complexity of the task is rarely well understood.
The number of people that have the proper experience to guide something like that to success is relatively small because they happen relatively rarely.
> "I'm convinced it would have been cheaper to just clean that code up in place"
Generally agreed. I'm generally very bearish on large-scale rewrites for this reason + political/managerial reasons.
The trick with any organization that wants to remain employed is demonstrating progress. "Go away for 3 years while we completely overhaul this." is a recipe for getting shut down halfway through and reassigned... or worse.
A rewrite, however necessarily, must always be structured as multiple individual replacements, each one delivering a tangible benefit to the company. The only way to stay alive in a long-term project is to get on a cadence of delivering visible benefit.
Importantly doing this also improves your odds of the rewrite going well - forcing yourself to productionize parts of the rewrite at a a time validates that you're on the right track.
Part of our issue with the rewrite is we went from C++ to C++. For an embedded system in 2010 C++ was probably the right choice (rust didn't exist, though D or Ada would have been options and we can debate better elsewhere). Previous rewrites went from 8 bit assembly to C++, which is the best reason to do a rewrite: you are actually using a different language that isn't compatible for an in place rewrite (D supports importing C++ and so could probably be done in place)
Rewrites are much like any act of self improvement. People think grand gestures and magical dates (like January 1 or hitting rock bottom) are the solution to turn your life around. But it’s little habits compounding that make or break you. And it’s new habits that kill old ones, not abstinence.
I worked with another contractor for a batshit team that was waiting for a rewrite. We bonded over how silly they were being. Yeah that’s great that you have a plan but we have to put up with your bullshit now. The one eyed man who was leading them kept pushing back on any attempts to improve the existing code, even widely accepted idioms to replace their jank. At some point I just had to ask him how he expected all of his coworkers to show up one day and start writing good code if he won’t let them do it now? He didn’t have an answer to that, and I’m not even sure the question landed. Pity.
The person who promised him the rewrite got promoted shortly before my contract was up. This promotion involved moving to a different office. I would bet good money that his replacement did not give that team their rewrite. They’re probably either still supporting that garbage or the team disappeared and someone else wrote a replacement.
That whole experience just reinforced my belief that the Ship of Theseus scenario is the only solution you can count on working. Good code takes discipline, and discipline means cleaning up after yourself. If you won’t do that, then the rewrite will fall apart too. Or flame out.
Whether you rewrite or refactor the code is not so much the point of my comment - it's more that you should first determine what you actually need, in consultation with the project stakeholders, get rid of whatever you don't need, and then you can decide whether you need to rewrite or refactor. Cutting away the bloat will give you a better perspective on that decision.
Personally, I would lean towards refactoring - a rewrite is the "declare bankrupcy" stage of technical debt and should only be considered in extremis. For example, the original codebase was written in ColdFusion and in 2025 you can't find any ColdFusion developers (or anyone in their right mind who wants to become a ColdFusion developer). But in any case, rewriting a trimmed down codebase is easier than trying to replicate features you don't need any more.
In the same way people go to their doctor or dentist or mechanic too late and prevention and sometimes even the best treatments are off the table, software developers (particularly in groups vs individually) love to let a problem fester until it’s nearly impossible to fix. I’m constantly working on problems that would have been much easier to address 2 years ago.
The problem is that once you take the VC coin, you are pushed towards hyper-scale. If you don't take the VC coin it's a much harder and longer path to self-sustainability, unless you have some way to fund yourself e.g. consulting. 37 Signals is the model here, but they are super-exceptional (they created Rails, after all).
Then having got there, a VC-funded competitor will just roll over you as they'll have better connections and funding.
They are great for throwaway hobbyist side projects where you don't want to worry about AWS billing horror stories or more expensive offerings like Digital Ocean or Linode.
I would not recommend them for a serious, money-on-the-table business.
I only use them for money-making projetcs. Based on my own experience and what I read online, you need to be careful with:
* crypto mining (I used it when it wasn't causing much trouble but I noticed my nodes were constantly attacked at a ratio I newer saw for other servers); IIRC Hetzner's current ToS forbid crypto mining
* things in legally grey area which might be legal in some places but not so in others, especially in the EU
* protect your servers well; if you become a victim of an attack and your servers will start attacking other, Hetzner will isolate them and notify you so that you can solve the problem
Other than that, the only problems I had in the last 15 or so years are failing bare-metal components that they promptly replaced, that's all.
Their ToS forbids not just the crypto mining (that was extremely reasonable to ban ten years ago, but it's moot today) but also some arbitrary financial technologies they don't like.
I disagree. It's not just the nuisance of wasted clock cycles. It also makes the network a juicy target for hackers. To anyone about to reply "you don't think people hack them now?", how do you think the correlation of attack sophistication and frequency looks for a network with/without a bunch of FREE MONEY inside? :)
Such as storing, uploading, downloading and serving transactions in a specific particular way called blockchain or distributed ledger. They have also explicitly forbidden storing blockchain data on their servers and having anything auxiliary related to it.
It is obviously a hostile language created by lawyers who did not spend much time researching the subject.
Of course it's unenforceable in practice and that is why a hefty chunk of Ethereum nodes are hosted on Hetzner for years and years with no problems.
I would absolutely use Hetzner for a real money-on-the-table business. You just have to know what you are up to and do your cost-benefit analysis.
I actually moved a business of ~100 FTEs from AWS to Hetzner once. Aside from the migration cost, the price was roughly 25% of AWS.
At the end, the biggest gain was not monetary, but human.
For years, that business could retain skilled engineers who had the opportunity to work close to bare metal, caring about the nitty-gritty technical details of backups, failover and high availability.
And they did not even cost much. That they had so much leeway in designing the system instead of "relying on the cloud" was a major retainer.
I left many years ago, the business switched frameworks since then but they stayed on Hetzner.
P.S. Yes, that was before Hetzner Cloud became a thing )
You would terminate someone for...having an opinion? They didn't mention the company they worked for (if indeed it is their company and not some made-up example).
Little secret: outside of self-proclaimed "leaders" in the Linkedin bubble, most normal people think like the writer, if not put so eloquently. They have jobs to do, and know how to do them, and do not appreciate being dragged into a 4 hour meeting to listen to bullshit. Of course they'll do it if they are told to. But if you are a "leader" you would be conscious of their time and not waste it on self-congratulatory claptrap.
For long meetings I've dreamed about having a taxi style fare meter running on the screen. It would add up all the wages of the people present and give a running total for the speaker so they know the (minimum) cost of the meeting.
Normally I hate timesheets, but there is some satisfaction in putting "Company meeting: 4 hours" into a timesheet and knowing the managers will have a mild heart attack when those 4 hours are multiplied for every person across the company when they look at the end of the month report.
Honestly, what is the market for these SAAS starters these days? Is anyone making serious money, or even a modest side income, with some web app? It seems the low-hanging fruit is well and truly picked at this point and building something that will earn you decent money requires a lot of time and money investment in a vertical niche, not yet-another-project-management-tool you can put together in a week.
Then you have to rely on getting the job by other means than sending your CV. In other words networking.
Personally I don't apply to public job listings any more, even when I match all requirements. They are a waste of everyone's time. But networking has its limits.
You can refactor, but you're also wasting time optimizing code you don't need. A better approach is to sit down with rest of the company and start cutting away the bloat, and then refactor what's left.