Rendered at 22:08:31 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
dkarl 1 hours ago [-]
The "When touching it is the right call" is the tricky part, because it contains this very subjective exception: "Every new feature costs three times what it should because of the design, and you can show the trend."
I've been in situations where I was sure this was true. I've also been in situations where the person claiming it simply refused to become competent in the language, framework, or persistence technology that the system was built on.
Also subjective: "The business needs a capability the current code was never shaped to grow into." Most of the times I've heard this brought up, it's not that you need a re-write, but you need a re-architecture. Often the existing system can continue to do its job as it always has, but in a new architectural context. Or 90% of the code can stay the same, while the application it runs in is changed, for example from a web service to a Kakfa consumer. (This is why it's so important to avoid languages and frameworks that are tightly bound to an architectural choice.)
bbsnly 22 minutes ago [-]
I really like your comment about "re-architecture". I 100% agree with you.
felooboolooomba 4 minutes ago [-]
With a title like that you have to back it up. It's a shallow article.
> why it was worth doing, because it wasn't, at least not to the business. The application did the same job for the same users at the same speed as before.
Application have many other properties then "doing their job". Running cost, maintainability, ... it's endless. Any of them going seriously wrong can tank the company owning it.
But I agree, rewrites are very often bad. I've been the customer of two banks that spent years to rewrite their online bank. It was crap and missing features! But maybe they got something out of it.
_doctor_love 1 hours ago [-]
A perennial insight which has been articulated many times before. This feels like one of those stages all engineers pass through at some point in their growth journey. Chesterton's Fence and all that (or Joel Spolsky's "never do full rewrites" advice).
mark-r 1 hours ago [-]
I love Chesterton's Fence and haul it out whenever I can. Even though it's about 100 years old and the context is barely relevant anymore.
lostglass 11 minutes ago [-]
[dead]
argee 1 hours ago [-]
> I barely knew CakePHP, so every file looked wrong to me. I knew Laravel, and I loved working in it. So on my own time, unasked, I ported the thing piece by piece, swapping in Illuminate packages until the old framework was gone.
Title is somewhat clickbaity, because these actions are not what people are going to think of when they think of a rewrite in a corporate environment.
By the way, I was an early employee at Amazon.com and the website’s rendering engine was rewritten three times, each time unlocking a new level of productivity without which the site (as well as the velocity of teams) would have slowed to a crawl, and the company would have probably died.
bbsnly 11 minutes ago [-]
The Rust community would disagree with you.
dijksterhuis 1 hours ago [-]
good rewrites are good. bad rewrites are bad.
you’ll only find out which kind of rewrite you’re doing once you start it.
hellisothers 2 hours ago [-]
Is this news to anybody? Feels like I should just point AI and several “foundations of software engineering” and have it churn out blog posts for each chapter.
bbsnly 33 minutes ago [-]
Despite it not being news for lots of people, I am always surprised how many actually still fall into the trap. Somehow, software engineers are very opinionated people, and opinions are often a reason to begin such a journey of rewriting a piece of software that needs no rewrite.
Churning out the blog posts isn't a bad idea if it's true. Repetition isn't inherently bad.
brucejackson 2 hours ago [-]
This rings so very true. Have been in the software business for too many decades and having inherited other people's code many many times, there is always the decision about what to do going forward. Leave it running, refactor it gently or rip and replace. Each has it's own set of traps that need to be carefully considered.
dude250711 21 minutes ago [-]
If you commit to being around for all the support calls, then do any rewrites you want. But the rewriters unfortunately tend to use it to pad out CVs and move on.
blinkbat 2 hours ago [-]
serving the engineer _does_ serve the business, ultimately.
sandeepkd 21 minutes ago [-]
I think this is the key here. Most engineers go through some gradual phases from what I have learnt, initial, when they are confident of being able to accomplish everything, second when they feel they now understand how things work and third when they know that there is a lot more to it.
This essay sounds more like a second phase. Rewriting something that you do not understand makes sense if most people on team do not understand it well, and are supposed to actively contribute to it OR you are at an inflection point where the choice of architectural or foundational decisions made back then become a bottleneck in every day performance or feature development.
Business is looking it from the cost benefit perspective and they would not approve it at the cost of company time and money if it doesnt makes sense to them. Your ability to fool them for your motivations may be a different angle, still they are the ones making the call.
CognitiveLens 1 hours ago [-]
This is my thinking as well. Although the 'never do full rewrites' rule is canon for most of the software world, I have led rewrites of two large front-end applications to great success - replacing an app that 'worked' but took an order of magnitude more time to iterate on than the codebase that replaced it.
That said, it's probably more dependent on what a 'full' rewrite actually is - I would be much more reluctant for a full-stack rewrite, particularly of a mature codebase with a lot of accumulated business logic. At least on the front end you can always push to move business logic upstream where it belongs.
bbsnly 27 minutes ago [-]
[dead]
vjvjvjvjghv 51 minutes ago [-]
Not necessarily. I have seen it plenty of times where a new contributor/manager comes in, declares all existing code is crap and needs to be rewritten to their favorite language/framework/cloud provider.
A lot of rewrites could be avoided if people spent some time to actually understand what was done before. It’s a pretty safe assumption that the people who worked on the codebase before were as smart as you.
yallpendantools 24 minutes ago [-]
> It’s a pretty safe assumption that the people who worked on the codebase before were as smart as you.
Amen! Code is never written in a vacuum. Code is never shaped only by engineering but by business and organizational compromises as well. I hate those guys who declare we absolutely must do sweeping changes to the codebase/architecture so that we are in line with the latest best practices after spending an hour with the codebase. As if the guys who spent the last 3+ years staring and building on said codebase didn't know any better (unless of course you were hired specifically because you ought to know better!).
sandeepkd 19 minutes ago [-]
> It’s a pretty safe assumption that the people who worked on the codebase before were as smart as you.
The motivations and goals back then could have been different, specially in the case of MVPs
bbsnly 30 minutes ago [-]
A friend of mine is migrating the company's IaC to TS as we speak because a new manager who recently joined the company decided to do it with no good reason.
jghn 52 minutes ago [-]
Iff the engineer's incentives are aligned with the businesses. Which is far from always true.
bluefirebrand 3 minutes ago [-]
If so this is a problem on the business side, they're the one controlling a big part of the engineer's incentives
honeycrispy 1 hours ago [-]
Right? A codebase nobody wants to work on results in a crappy, broken product.
mark-r 1 hours ago [-]
Given enough time, that describes every codebase that exists.
1 hours ago [-]
breakds 2 hours ago [-]
Engineer: but business is not my problem.
yallpendantools 48 minutes ago [-]
Software engineering is much easier if you assume you have no users. Except for the part where you have to make money, that is.
wmeredith 44 minutes ago [-]
Unemployed engineer: business is my problem.
LoganDark 1 hours ago [-]
The business is certainly one of the most important constraints as an engineer.
watwut 2 hours ago [-]
> For a few weeks one summer I woke at 4am to rewrite code my employer had already paid someone to write.
I mean, if you do it at 4am, you are sleep deprived by the day two and thus unable to stop yourself from something stupid.
bbsnly 2 hours ago [-]
Only if you do not get 7-8 hours of sleep ;)
darth_avocado 26 minutes ago [-]
Very rarely have I heard an engineer look at a functioning piece of software and go “let me rewrite this because it’s not a language or framework I am familiar with and fond of”. If that does happen, it’s usually inexperienced (or bad) engineers.
Rewrites usually start with a gap in what is available and what is needed: missing functionality, existing frameworks getting obsolete, difficultly maintaining code because of the existing implementation complexity, costs, scalability issues, compliance challenges, etc. Most of these things serve the business more than the engineers.
bbsnly 17 minutes ago [-]
> If that does happen, it’s usually inexperienced (or bad) engineers.
I agree with you. And that is where I was at that time. I did not have enough experience as a Software Engineer, nor with CakePHP — hence decided to rewrite. Mistakes were made.
I've been in situations where I was sure this was true. I've also been in situations where the person claiming it simply refused to become competent in the language, framework, or persistence technology that the system was built on.
Also subjective: "The business needs a capability the current code was never shaped to grow into." Most of the times I've heard this brought up, it's not that you need a re-write, but you need a re-architecture. Often the existing system can continue to do its job as it always has, but in a new architectural context. Or 90% of the code can stay the same, while the application it runs in is changed, for example from a web service to a Kakfa consumer. (This is why it's so important to avoid languages and frameworks that are tightly bound to an architectural choice.)
> why it was worth doing, because it wasn't, at least not to the business. The application did the same job for the same users at the same speed as before.
Application have many other properties then "doing their job". Running cost, maintainability, ... it's endless. Any of them going seriously wrong can tank the company owning it.
But I agree, rewrites are very often bad. I've been the customer of two banks that spent years to rewrite their online bank. It was crap and missing features! But maybe they got something out of it.
Title is somewhat clickbaity, because these actions are not what people are going to think of when they think of a rewrite in a corporate environment.
By the way, I was an early employee at Amazon.com and the website’s rendering engine was rewritten three times, each time unlocking a new level of productivity without which the site (as well as the velocity of teams) would have slowed to a crawl, and the company would have probably died.
you’ll only find out which kind of rewrite you’re doing once you start it.
Churning out the blog posts isn't a bad idea if it's true. Repetition isn't inherently bad.
This essay sounds more like a second phase. Rewriting something that you do not understand makes sense if most people on team do not understand it well, and are supposed to actively contribute to it OR you are at an inflection point where the choice of architectural or foundational decisions made back then become a bottleneck in every day performance or feature development.
Business is looking it from the cost benefit perspective and they would not approve it at the cost of company time and money if it doesnt makes sense to them. Your ability to fool them for your motivations may be a different angle, still they are the ones making the call.
That said, it's probably more dependent on what a 'full' rewrite actually is - I would be much more reluctant for a full-stack rewrite, particularly of a mature codebase with a lot of accumulated business logic. At least on the front end you can always push to move business logic upstream where it belongs.
A lot of rewrites could be avoided if people spent some time to actually understand what was done before. It’s a pretty safe assumption that the people who worked on the codebase before were as smart as you.
Amen! Code is never written in a vacuum. Code is never shaped only by engineering but by business and organizational compromises as well. I hate those guys who declare we absolutely must do sweeping changes to the codebase/architecture so that we are in line with the latest best practices after spending an hour with the codebase. As if the guys who spent the last 3+ years staring and building on said codebase didn't know any better (unless of course you were hired specifically because you ought to know better!).
The motivations and goals back then could have been different, specially in the case of MVPs
I mean, if you do it at 4am, you are sleep deprived by the day two and thus unable to stop yourself from something stupid.
Rewrites usually start with a gap in what is available and what is needed: missing functionality, existing frameworks getting obsolete, difficultly maintaining code because of the existing implementation complexity, costs, scalability issues, compliance challenges, etc. Most of these things serve the business more than the engineers.
I agree with you. And that is where I was at that time. I did not have enough experience as a Software Engineer, nor with CakePHP — hence decided to rewrite. Mistakes were made.