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

11–20 of 71 posts

Re: Most rewrites serve the engineer, not the business

#12

Post by dkarl »

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

Re: Most rewrites serve the engineer, not the business

#13

Post by CognitiveLens »

blinkbat wrote: post #6

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

Re: Most rewrites serve the engineer, not the business

#14

Post by mark-r »

_doctor_love wrote: post #8

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

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.

Re: Most rewrites serve the engineer, not the business

#16

Post by argee »

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

Re: Most rewrites serve the engineer, not the business

#19

Post by vjvjvjvjghv »

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.

Post reply on HN