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

Perfection is not over-engineering

var0.xyz

Post reply on HN
Print view View original

61–70 of 132 posts

Re: Perfection is not over-engineering

#61

Post by esikich »

nickelpro wrote: post #8

"We're not trying to build a perfect solution here" is not something said to assuage over-engineering or encourage sloppy work. It's said to head off a specific complaint from a specific kind engineer who will object that the proposed solution won't work because it doesn't cover some obscure edge case which rarely comes up in production. "We're not trying to build a perfect solution here" is saying "We acknowledge no…

My grandpa used to say "we're not building a piano" when doing things like building a quick shelf or something in the basement and be done after a quick measure and a few cuts. My other grandpa would spend an entire day measuring, sanding, pulling out a router etc. Both valid, but if you just need something to put some paint cans on, it doesn't require a day of work.

Re: Perfection is not over-engineering

#63

Post by __MatrixMan__ »

smaudet wrote: post #59
dasil003 wrote: post #30

Earlier quoted context omitted.

I get what you mean about the conflict of interest for consumer software, but I don’t think a product mindset is inherently toxic. It’s more a function of where you are in the enshittification cycle.

Products tend to be someone else's tool. Like you hint at, though, a tool is useful immediately and without end (at a particular task - windows operating systems remain useful despite whatever current version is being sold), the product is often an attempt to continuously derive value from the tool (attach a time limited license, offer "upgrades", new features, etc.). A service is more like a product than a tool - se…

> Products tend to be someone else's tool

I like this. The question is really whether you're facing the "business end of the stick" or not (although stick isn't quite right here, because not all software has both ends).

Re: Perfection is not over-engineering

#64

Post by stouset »

__MatrixMan__ wrote: post #5

I'm all for pushing back against "let's not make perfect the enemy of good." I hear that all the time in reference to software that is usually quite bad, and often a little evil to boot--nothing good anywhere in sight except some poor schmuck trying to find a way to make their job something worth taking pride in. I'm not sure I agree that systems are products though. The product mindset is toxic. It means that you've…

The number of times I've heard that phrase used to justify shipping absolute crap utterly dwarfs the times it's been used to prevent over-engineering something that's already in a good state.

In a thirty year career of software engineering, I haven't once come across one of these mythical perfectionists that everyone is constantly retelling cautionary tales of, who endlessly rewrites perfectly serviceable software and never releases it. I have, however, worked at multiple companies that have collapsed under the weight of their unmaintainable spaghetti tech stacks.

Re: Perfection is not over-engineering

#65

Post by sandeepkd »

In the absence of concrete examples its hard to say what is OP trying to optimize for. Optimism is good, however at the end of the day everything is a trade off, the cost has to be paid for all decisions. A good design is all about optimizing when, where and how you push those costs.

Re: Perfection is not over-engineering

#66

Post by cj »

Ekaros wrote: post #60
nickelpro wrote: post #8

"We're not trying to build a perfect solution here" is not something said to assuage over-engineering or encourage sloppy work. It's said to head off a specific complaint from a specific kind engineer who will object that the proposed solution won't work because it doesn't cover some obscure edge case which rarely comes up in production. "We're not trying to build a perfect solution here" is saying "We acknowledge no…

What is the qualifier of "rarely". One in ten, one in hundred, one in thousand? What is the failure in these cases? I could accept rarely if that is one in trillion to one in quadrillion range say. Truly rare cases. But not if it might be for seen reasonably.

Very few businesses care about accommodating "one in a trillion" edge cases. (Most would call that over-engineering IMO)

Re: Perfection is not over-engineering

#69

Post by nickelpro »

Ekaros wrote: post #60
nickelpro wrote: post #8

"We're not trying to build a perfect solution here" is not something said to assuage over-engineering or encourage sloppy work. It's said to head off a specific complaint from a specific kind engineer who will object that the proposed solution won't work because it doesn't cover some obscure edge case which rarely comes up in production. "We're not trying to build a perfect solution here" is saying "We acknowledge no…

What is the qualifier of "rarely". One in ten, one in hundred, one in thousand? What is the failure in these cases? I could accept rarely if that is one in trillion to one in quadrillion range say. Truly rare cases. But not if it might be for seen reasonably.

"None of the deployments under consideration for this new initiative use that mechanism, that other deployments might is irrelevant to the internal product we are building"

In my space this is usually something like, "X won't work on POSIX make", being a reason not to add X to the build system. Well, it works on Ninja, and on GNU make, so it just won't work on POSIX make and the handful of deployments still using POSIX make just won't use X.

Re: Perfection is not over-engineering

#70

Post by ozim »

nickelpro wrote: post #8

"We're not trying to build a perfect solution here" is not something said to assuage over-engineering or encourage sloppy work. It's said to head off a specific complaint from a specific kind engineer who will object that the proposed solution won't work because it doesn't cover some obscure edge case which rarely comes up in production. "We're not trying to build a perfect solution here" is saying "We acknowledge no…

I find it that in wild it is quite often used by product people to push crap ASAP because they don’t want to spend time finding out even basic constraints in the system they supposed to know like the back of their hand.

Then engineers are on the hook because they run into those constraints while building and everyone always blames „those lazy software developers” ;)

Post reply on HN