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

Let's Rewrite Everything

martinpeck.com

Post reply on HN
Print view View original

11–20 of 61 posts

Re: Let's Rewrite Everything

#11

Post by eternityforest »

tinco wrote: post #6

This is madness. There's no real advice about rewrites in this article. The reality of rewrites is that they often fail, cost a ridiculous amount of time and effort, don't actually fix the original problem and/or bankrupt the company. You can't just wave away those realities with "think about the downsides". I have participated in a few (small) rewrites that were successful, and this would be my advice: Don't rewrite…

I'm convinced that bad rewrites happen because coders get bored and care more about the possibility of a little bit better code, then the whole future of the company.

Necessary rewrites happen because they did too much YAGNI thinking in version 1.

Re: Let's Rewrite Everything

#12

Post by eternityforest »

otabdeveloper4 wrote: post #10
hw wrote: post #7

Had met my share of engineers who wanted to rewrite everything from scratch into microservices and the reason they gave was ‘well microservices scales and monoliths dont’ - without taking into account the maturity of the existing application, the scale it already operates at and the scale we expect to operate at, the team resources and skills to required to support the rewrite, and the business requirements and goals…

> programmers want to program and get paid more The shocker. (That said, yes, motivating developers is a thorny problem.)

I wonder if any companies purposely avoid hiring any dedicated professional developers, and have everything done by other professionals who happen to know some code, and how it works.

Developers always come with their own perverse incentive. They like the new, the clever, the smart, and the simple, and rarely appreciate the battle tested and extensible.

Re: Let's Rewrite Everything

#13

Post by tinco »

eternityforest wrote: post #11
tinco wrote: post #6

This is madness. There's no real advice about rewrites in this article. The reality of rewrites is that they often fail, cost a ridiculous amount of time and effort, don't actually fix the original problem and/or bankrupt the company. You can't just wave away those realities with "think about the downsides". I have participated in a few (small) rewrites that were successful, and this would be my advice: Don't rewrite…

I'm convinced that bad rewrites happen because coders get bored and care more about the possibility of a little bit better code, then the whole future of the company. Necessary rewrites happen because they did too much YAGNI thinking in version 1.

It annoys me so much that after honing my skill as an engineer for 15 years now I still fall into the trap of not enough YAGNI thinking. There's a precarious middle ground there for sure. Even though I still fall into the trap of over designing, I believe it's way worse than under designing. I don't remember a single instance where a 'YAGNI' under designing cost us much except designing and implementing the feature the right way, a cost which we'd incur anyway. In contrast I've caused my team to work with an overly complex codebase for years on multiple occasions.

Re: Let's Rewrite Everything

#14

Post by RedShift1 »

I think a lot of rewrites happen because new people come along and they are not interested in reading and learning existing code. They just want to write new code and in their mind "the way I do it is better". A prime example is the Javascript ecosystem with such a high churn rate it caused a new kind of burnout: Javascript fatigue. Programmers seem to forget when you throw away code, you're not just throwing away text, you are throwing away years of accrued knowledge.

Re: Let's Rewrite Everything

#16

Post by martinpeck »

theonething wrote: post #4

> Good luck with your rewrite! I’m sure it’ll be everything you hope it’ll be. It’ll probably be finished way quicker than you expect, and life will be perfect afterwards. The author seems to be generally pro rewrite in his article so I can't tell if this is sarcasm here.

100% sarcasm

Re: Let's Rewrite Everything

#17

Post by throwaway984393 »

tinco wrote: post #6

This is madness. There's no real advice about rewrites in this article. The reality of rewrites is that they often fail, cost a ridiculous amount of time and effort, don't actually fix the original problem and/or bankrupt the company. You can't just wave away those realities with "think about the downsides". I have participated in a few (small) rewrites that were successful, and this would be my advice: Don't rewrite…

I just started writing up a formal process on how to improve the small bits gradually. It's actually way more complicated than you think at first... Presenting a user problem, identifying root causes, proposing a solution, mapping out the individual components, listing all of the steps needed to complete a solution, working on each step, and validating each resulted in an improvement based on measurements. There's all these little details to consider to get each one of those right. Maybe this is all well described in some software project management book, but I've not seen it.

Re: Let's Rewrite Everything

#18

Post by hn_acc_2 »

eternityforest wrote: post #12
otabdeveloper4 wrote: post #10

Earlier quoted context omitted.

> programmers want to program and get paid more The shocker. (That said, yes, motivating developers is a thorny problem.)

I wonder if any companies purposely avoid hiring any dedicated professional developers, and have everything done by other professionals who happen to know some code, and how it works. Developers always come with their own perverse incentive. They like the new, the clever, the smart, and the simple, and rarely appreciate the battle tested and extensible.

Having seen several projects written by people who "happen to know some code," I can tell you there's a good reason this hasn't caught on.

These sort of people can work the very foundations of the company into an ungodly quagmire that would send you screaming back to the fad-chaser dev in a heartbeat.

Also despite the meme, most mid-senior devs are actually keen on making their contributions valuable to the business, having gotten over this phase of fascination with new tools

Re: Let's Rewrite Everything

#19

Post by eternityforest »

tinco wrote: post #13
eternityforest wrote: post #11

Earlier quoted context omitted.

I'm convinced that bad rewrites happen because coders get bored and care more about the possibility of a little bit better code, then the whole future of the company. Necessary rewrites happen because they did too much YAGNI thinking in version 1.

It annoys me so much that after honing my skill as an engineer for 15 years now I still fall into the trap of not enough YAGNI thinking. There's a precarious middle ground there for sure. Even though I still fall into the trap of over designing, I believe it's way worse than under designing. I don't remember a single instance where a 'YAGNI' under designing cost us much except designing and implementing the feature t…

The only time I've regretted overdesigning is when there's been significant original design work involved.

I don't think I've ever regretted overdesigning to meet a common standard or match how everyone else does something.

A lot of the YAGNI I see is in the form of "We don't need a framework, just do vanilla JS" or "I only need one of the features of this library, I'll just write it myself".

Almost all of my own big tech regrets have to do with building something "innovative". Even when they've solved the problem better than existing solutions they often become regrets, just for the simple fact that they aren't better by enough to justify the nonstandardness.

Re: Let's Rewrite Everything

#20

Post by suifbwish »

eternityforest wrote: post #11
tinco wrote: post #6

This is madness. There's no real advice about rewrites in this article. The reality of rewrites is that they often fail, cost a ridiculous amount of time and effort, don't actually fix the original problem and/or bankrupt the company. You can't just wave away those realities with "think about the downsides". I have participated in a few (small) rewrites that were successful, and this would be my advice: Don't rewrite…

I'm convinced that bad rewrites happen because coders get bored and care more about the possibility of a little bit better code, then the whole future of the company. Necessary rewrites happen because they did too much YAGNI thinking in version 1.

I think a lot of rewrites happen because of too much adderall lol
Post reply on HN