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

41–50 of 71 posts

Re: Most rewrites serve the engineer, not the business

#41

Post by cadamsdotcom »

Never fix a bug without having first written a red test.

Never just write code. Always write red tests first.

In fact you can do even better and have your agent write end-to-end tests first as acceptance tests, have it witness them fail, then have it do red/green at the unit/component/integration level. Once it’s done the e2e tests pass, have it send the code off for linting and self-review.

If you are vigilant you’ll end up with a trustworthy validation suite. And with that (especially with e2e coverage), you can refactor and rewrite as much as you like.

Re: Most rewrites serve the engineer, not the business

#42

Post by joe_the_user »

Yahoo bought Viaweb from Paul Graham and rewrote the Lisp application in C++ and Perl. Reports are the results were strictly inferior but it achieved the goal of not having to rely on Lisp programmers.

Part of Yahoo's business is/was hiring programmers reasonably cheaply and controlling them reasonably easily - to allow Yahoo itself to sell parts or all of itself.

So things aren't quite a simple as "this doesn't serve the product", sometimes the engineers (and their replaceability) are part of the product.

Re: Most rewrites serve the engineer, not the business

#43

Post by eithed »

felooboolooomba wrote: post #35

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, re…

[flagged]

Re: Most rewrites serve the engineer, not the business

#44

Post by malux85 »

dkarl wrote: post #12

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…

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

To all managers out there, this is a strong negative signal in the employees mindset, and a strong positive signal that there was a mistake in hiring. Eliminate this type of behavior immediately and if the person wont change then fire them (inability to change is also another red flag).

There is a small chance that there's strong logical reasons for a desire to fundamentally change an underlying technology, but the comment above says they "simply refused to become competent in ....... that the system is built on" and as a ex-google senior engineer of 20 years, I can 100% confidently say that the first step to large scale refactor is to understand and be competent in the existing system!

Re: Most rewrites serve the engineer, not the business

#45

Post by stingraycharles »

dkarl wrote: post #12

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…

Everything about all this has always been subjective, which is what separates good engineers from bad ones. Bad ones do refactorings that add very little value, good ones do it the right way, at the right time.

It’s also why, as you become older, the more senior you are the more you start to appreciate “boring” solutions and avoid fancy abstractions. It almost always serves the business much better.

Re: Most rewrites serve the engineer, not the business

#47

Post by plasticeagle »

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 the entire product without management buy-in, then that's an organisational and a discipline problem.

Added to which, of course, maintainability and build-ability both matter an enormous amount. Work to improve both of those things will improve the business.

Re: Most rewrites serve the engineer, not the business

#48

Post by darth_avocado »

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.

I would classify them in the “ existing languages/frameworks getting obsolete” bucket.

Re: Most rewrites serve the engineer, not the business

#49

Post by bluefirebrand »

malux85 wrote: post #44
dkarl wrote: post #12

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…

> 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. To all managers out there, this is a strong negative signal in the employees mindset, and a strong positive signal that there was a mistake in hiring. Eliminate this type of behavior immediately and if the person wont change then fire them (…

> 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 generalist nowadays

Having strong preferences about the tech you like to use and the way you like to build is fine. Find the employers with projects and teams that match your preferences rather than trying to crowbar yourself into everyone else's preferences

Re: Most rewrites serve the engineer, not the business

#50

Post by dijksterhuis »

vjvjvjvjghv wrote: post #19
blinkbat wrote: post #6

serving 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 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 not always a safe assumption.

planned a full rewrite of a product at last company. i knew things were fucked 3 months in. i started really planning the rewrite 1.5 years in.

that year taught me just how fucked it was: bugs galore, race conditions, crashing frontend, testing in customer environments, data loss, rolled their own security (users from any group could login to any other instance).

previous big brained devs really fucked it and there wasn’t much of anything to show for it.

i fixed a bunch of it. but it still needed a rewrite because they had built the wrong thing. which was the bigger issue i realised 3 months in.

Post reply on HN