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

91–100 of 132 posts

Re: Perfection is not over-engineering

#91

Post by nulltrace »

titzer wrote: post #41

I think over-complicated and over-engineered are not the same thing. Over-complicated is adding too many features, too much mechanism, too many moving parts. Over-engineering is far exceeding the requirements in an unhelpful way. For example: build me a treehouse. Said treehouse could probably be made of wood. If you made it out of concrete and steel, it might be a heck of a lot stronger and last a heck of a lot long…

I think your concrete treehouse counts too though. Add a shower and suddenly you need plumbing, drainage, the structure has to hold more weight. The overcomplicated part drags the overengineered part along with it. They pretty much collapse into the same thing.

Re: Perfection is not over-engineering

#92

Post by Night_Thastus »

Knowing your constraints perfectly is impossible, and takes more and more effort the closer you get.

And frankly, they change on a regular basis. By the time you figure them out that perfectly, they're invalidated. A new feature is suddenly needed by the customer, a bottleneck that wasn't there before appears now, scale changes, consumer preferences change, new hardware and software come out, everything changes.

IMO, the best engineering is 80/20. Get 80% of the result you want for relatively little effort and complexity, and don't sweat the remaining 20%. Embrace the imperfection. Get it done in the simplest, most obvious way - even if you know it has limitations, edge cases, and some things missing.

Knowing how to get that 80% is extremely hard (and how to do it without causing lots of problems down the road), but I think senior engineers get pretty good at it. And if you absolutely need to, get another 80% of that remaining 20%.

Re: Perfection is not over-engineering

#94

Post by pilgrim0 »

> The shape of the solution only becomes obvious once you treat the system as a product and define the requirements honestly.

The “honest” part is the important one. It’s also the hardest. It’s so tempting to project preferences onto a new development, which tends to confuse the distinction between desire and necessity. There’s so many things we want to try. Maybe having lots of personal projects to vent the need for novelty helps one to make good choices when it’s critical that they must be right.

Re: Perfection is not over-engineering

#95

Post by BloodyIron »

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

So is a screwdriver a tool or a product?

I think you're getting caught up on nomenclature and limited sample sizes.

Re: Perfection is not over-engineering

#96

Post by __MatrixMan__ »

BloodyIron wrote: post #95
__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…

So is a screwdriver a tool or a product? I think you're getting caught up on nomenclature and limited sample sizes.

What it is to you depends on if you want to sell a screwdriver or if you want to drive a screw.

If you're looking for somebody to design a screwdriver for you, you're better off with the guy who wants to drive a screw.

Re: Perfection is not over-engineering

#97

Post by ChrisMarshallNY »

bch wrote: post #86
__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…

> “let's not make perfect the enemy of good." Nuanced, but I’ve heard “don’t let perfection be the enemy of completion ”, which is real in the cases of not shipping because one is constantly polishing/perfecting, or, as I heard sitting beside phk[0] at BSDCan commenting on rejecting some environmental sensors into FreeBSD, something to the effect of “We need ‘good’, not ‘good enough’.”, which draws a line at acceptin…

I always thought of that as “yak-shaving,” or “bikeshedding.”

Quality takes longer. Sometimes, significantly longer, for many reasons. That’s why something top-shelf, costs so much more than commodity, when it doesn’t seem to have much more, in the way of features.

Many orgs aren’t interested in spending that much extra time on it (which is their prerogative). The customer base tends to be smaller, and a lot more fickle. It’s really difficult to make a living, doing top-Quality work.

Source: I worked for many years, for a company known for top-shelf stuff. I’m quite familiar with Quality as an everyday feature.

Re: Perfection is not over-engineering

#98

Post by stouset »

malux85 wrote: post #74
stouset wrote: post #64

Earlier quoted context omitted.

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

> 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 Oh, I have. A LOT! In my friend group theres at least 5 of these right now. They work day jobs (that they dislike), they try to build a side hustle but never get it off the ground because they endlessly rewrite perfectly s…

I couldn’t care less about solo developers who never release their hobby projects. The cautionary tales are always about potential coworkers, and as far as I can tell that stereotype simple doesn’t exist in the business world.

Re: Perfection is not over-engineering

#99

Post by gjvc »

jaggederest wrote: post #36
mtweak wrote: post #22

Earlier quoted context omitted.

I'm also wondering if "perfect" and "good enough" are not really as important now vs. when a team of software engineers had to spend sprints implementing features. The rate of iteration is faster now, the rate of regenerating entire code bases is days. We can perhaps over engineer /more/ today than before.

The real challenge is reigning in the size and complexity of the codebase if you're using AI to generate it. I have a bunch of skills (YAGNI / KISS inspired) but it still requires a significant amount of human effort. Knocked down about 9000 lines of cruft this month and I know there's another 10k in there sitting around.

"reining"

Re: Perfection is not over-engineering

#100

Post by bch »

ChrisMarshallNY wrote: post #97
bch wrote: post #86

Earlier quoted context omitted.

> “let's not make perfect the enemy of good." Nuanced, but I’ve heard “don’t let perfection be the enemy of completion ”, which is real in the cases of not shipping because one is constantly polishing/perfecting, or, as I heard sitting beside phk[0] at BSDCan commenting on rejecting some environmental sensors into FreeBSD, something to the effect of “We need ‘good’, not ‘good enough’.”, which draws a line at acceptin…

I always thought of that as “yak-shaving,” or “bikeshedding.” Quality takes longer. Sometimes, significantly longer, for many reasons. That’s why something top-shelf, costs so much more than commodity, when it doesn’t seem to have much more, in the way of features. Many orgs aren’t interested in spending that much extra time on it (which is their prerogative). The customer base tends to be smaller, and a lot more fic…

I love the social/cultural aspects of our engineering discipline.

> I always thought of that as “yak-shaving,” or “bikeshedding.”

I think of yak-shaving as ending up (by lack of discipline, or perhaps out of necessity) working on some supporting aspect of a supporting aspect of a supporting aspect... in service of the original task.

So, a potential time suck, for sure, but "perfection is the enemy of completion" doesn't have to be that deep - if we're throwing out more clever phrases and war stories - another phrase that comes to mind about just "polishing" and insisting it's not good enough to ship yet is it's (slightly NSFW)

"just like masturbation - it feels good, but you're only f*cking yourself". You need to ship.

Bike Shedding I think of as social - nearly Peter Principle in practice - everybody thinks they've got something to contribute to the construction of the bike shed because it's a thing that's easy to manage, and people want to be helpful and/or make a mark.

Post reply on HN