Engineer: but business is not my problem.
Unemployed engineer: business is my problem.
Most rewrites serve the engineer, not the business
21–30 of 71 posts
Re: Most rewrites serve the engineer, not the business
#22Is 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.
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.
Re: Most rewrites serve the engineer, not the business
#23serving the engineer _does_ serve the business, ultimately.
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.
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.
Re: Most rewrites serve the engineer, not the business
#24serving the engineer _does_ serve the business, ultimately.
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…
[dead]
Re: Most rewrites serve the engineer, not the business
#25Very 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.
Re: Most rewrites serve the engineer, not the business
#26serving the engineer _does_ serve the business, ultimately.
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.
> 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!).
Re: Most rewrites serve the engineer, not the business
#27The "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…
I really like your comment about "re-architecture". I 100% agree with you.
Re: Most rewrites serve the engineer, not the business
#28serving the engineer _does_ serve the business, ultimately.
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.
Re: Most rewrites serve the engineer, not the business
#29If 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.
Re: Most rewrites serve the engineer, not the business
#30serving the engineer _does_ serve the business, ultimately.
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.
> 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