alt Hacker Newsserving the engineer _does_ serve the business, ultimately.
Replies
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.
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.
Iff the engineer's incentives are aligned with the businesses. Which is far from always true.
Right? A codebase nobody wants to work on results in a crappy, broken product.
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.