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

31–40 of 71 posts

Re: Most rewrites serve the engineer, not the business

#31

Post by bbsnly »

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…

> If that does happen, it’s usually inexperienced (or bad) engineers.

I agree with you. And that is where I was at that time. I did not have enough experience as a Software Engineer, nor with CakePHP — hence decided to rewrite. Mistakes were made.

Re: Most rewrites serve the engineer, not the business

#32

Post by jacinda »

hellisothers wrote: post #5

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

Obligatory xkcd: https://xkcd.com/1053/

Churning out the blog posts isn't a bad idea if it's true. Repetition isn't inherently bad.

Re: Most rewrites serve the engineer, not the business

#33

Post by lostglass »

mark-r wrote: post #14
_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.

[dead]

Re: Most rewrites serve the engineer, not the business

#34

Post by bbsnly »

argee wrote: post #16

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

The Rust community would disagree with you.

Re: Most rewrites serve the engineer, not the business

#35

Post by felooboolooomba »

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, rewrites are very often bad. I've been the customer of two banks that spent years to rewrite their online bank. It was crap and missing features! But maybe they got something out of it.

Re: Most rewrites serve the engineer, not the business

#36

Post by bluefirebrand »

jghn wrote: post #18
blinkbat wrote: post #6

serving the engineer _does_ serve the business, ultimately.

Iff the engineer's incentives are aligned with the businesses. Which is far from always true.

If so this is a problem on the business side, they're the one controlling a big part of the engineer's incentives

Re: Most rewrites serve the engineer, not the business

#37

Post by marcosdumay »

dijksterhuis wrote: post #10

good rewrites are good. bad rewrites are bad. you’ll only find out which kind of rewrite you’re doing once you start it.

There are good heuristics to guess which kind is yours.

But they need expertize in software development and knowledge of the software's context to evaluate.

Re: Most rewrites serve the engineer, not the business

#38

Post by wl »

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.

Re: Most rewrites serve the engineer, not the business

#40

Post by atq2119 »

bbsnly wrote: post #27
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 really like your comment about "re-architecture". I 100% agree with you.

To expand on this, I've found that often, the best way to make a change is in two steps: First, make the change easy (the re-architecture). Second, make the change that is now easy.

My best software development experiences have been in cultures where this way of working was common.

It is a shame that these cultures are not more widely spread; and I mostly blame GitHub: the lack of good support for stacked PRs or patch series or whatever you want to call it makes it harder than it should be to work in this way.

Post reply on HN