Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Most rewrites serve the engineer, not the business

anatoliybabushka.com

Post reply on HN
Print view View original

61–70 of 71 posts

Re: Most rewrites serve the engineer, not the business

#61

Post by shalmanese »

plasticeagle wrote: post #47

The article is AI slop, obviously, like practically everything on the internet these days it seems. Awful writing, circling endlessly around the same point. The entire article could have been a single sentence. Which of course, is how it began. As a prompt. The article is also wrong. Or, at least, indicative of a broken relationship between management and engineering. If you have an engineer who can decide to rewrite…

What I'm curious about is why all AI written articles try to hide they were written with AI vs being open about it. I'd actually be far more willing to engage with an AI written article if the author shares the chat transcripts that lead them to the finished piece and I could load that context into my own session and ask additional questions/interrogate my own ideas branching from it.

Instead, people always try and pull the illusion as if the AI didn't exist.

Re: Most rewrites serve the engineer, not the business

#62

Post by jamesfinlayson »

wl wrote: post #38
darth_avocado wrote: post #25

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…

The big exception to this I've seen: The functioning bit of software was written in an oddball language that was already niche decades ago and the pool of developers who are competent to work on such a codebase is exceedingly small.

Yep - I was at a company that replaced something super obscure - I suspect the number of people in Australia that knew the tech was like 10 to 20. The tech was so obscure I don't think there was any path out other than a full rewrite.

A company I worked at decided to rewrite a Fortran system - I suspect that if they wanted to avoid a rewrite they could have started breaking bits off into C and mixing the languages at the linking step... but I understand their desire for a clean break - a rewrite was going to take years but a migration would have taken even longer and been even harder due to the lack of Fortran developers.

Re: Most rewrites serve the engineer, not the business

#63

Post by bluefirebrand »

malux85 wrote: post #54
bluefirebrand wrote: post #49

Earlier quoted context omitted.

> this is a strong negative signal in the employees mindset, and a strong positive signal that there was a mistake in hiring Agree that it's almost certainly a mistake in hiring but strongly disagree that it's a negative signal in the employees mindset Being specialized in one area is actually a good thing for many people and many roles. It's actually kind of bullshit that software companies expect everyone to be a g…

Strong (but polite) disagree. Domain knowledge is now commoditised more than ever, the only valuable employees are intellectually flexible ones with a can-do mindset, ideally more senior ones who will also take responsibility for the final output. Thats all we hire right now. With the exception of companies so huge that economies of scale make hyperspecialisation the sensible choice, however I ignored these because t…

Respectfully I remain unconvinced. Especially now with people thinking that AI basically does a baseline "good enough" on many things, specializing more deeply than the AI does is probably a really important thing for people

We already have a massive oversupply of generalists and AI makes that easier than ever, so idk. I think specialists are more valuable

Re: Most rewrites serve the engineer, not the business

#64

Post by jamesfinlayson »

darth_avocado wrote: post #25

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…

> let me rewrite this because it’s not a language or framework I am familiar with and fond of

I've been there at least once before and boy was that painful - I already have problems to deal with without someone from another team white-anting us with his ideas (that he doesn't need to maintain).

Re: Most rewrites serve the engineer, not the business

#65

Post by vinceguidry »

I was hired once to be the Rails guy on a team of competent web developers, that didn't know Rails. I spent two years slowly ironing out issues with the codebase. By the time I was done our velocity had increased to the point to where a two week sprint took three days to complete. They couldn't feed us enough work. We all got pretty good at ping pong.

Until one day our dear team lead rammed a full NodeJS rewrite down our throats.

Re: Most rewrites serve the engineer, not the business

#67

Post by tpoacher »

The main thing I feel this article gets wrong (or at least does not properly address) is that all the reasons provided seem subjective. Is there no objective (or at least semi-objective) process to do a cost-benefit analysis of a rewrite?

In ML e.g., there is the concept of a "ceiling analysis". I don't see why a variant of this wouldn't work here too.

Re: Most rewrites serve the engineer, not the business

#69

Post by vjvjvjvjghv »

yallpendantools wrote: post #26
vjvjvjvjghv wrote: post #19

Earlier quoted context omitted.

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 wit…

"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."

They also don't understand that their super shiny code will be legacy soon too.

Post reply on HN