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

51–60 of 132 posts

Re: Perfection is not over-engineering

#51

Post by MantisShrimp90 »

I believe perfection is a dirty word because it has a pernicious effect on the human mind.

Striving towards perfection too often leads to yes over-engineering but I think more importantly it also: leads to way too much bike shedding due to the need to be perfect and allot of even emotional baggage when we don't make that perfect things.

Even the author admits that their definition of perfect can only arise with stringent requirements and I'll take it a step further, maybe it was perfect for that problem at that time but guess what change happens all the time, and as architects we have to think about future problems as much as current ones. With that in mind I think that having something that is good in many scenarios is better than the thing that is perfect in the scenario you start in.

Re: Perfection is not over-engineering

#52

Post by axus »

__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 fixing bugs and backwards compatibility the enemy of shoveling out more features

Re: Perfection is not over-engineering

#53

Post by win311fwg »

var0xyz wrote: post #9
qsort wrote: post #2

I wouldn't say that "over-engineering means solving the wrong problem". It's possible that the idea is basically correct, but people are directing effort towards optimizing for constraints that don't really exist or can be dealt with once a better picture is in place, whether it's the mythical PMF or just "we now understand what the users want, let's build that". The worst clusterfuck I've ever worked on was a web ap…

> but the team was spending time building an absurd Rube-Goldberg contraption of microservices This is literally the example that I use, the most common case of over-engineering, having more microservices than team members. Microservices are the right solution for certain problems, but those were not problems they had. Some anecdotal evidence. I worked in many of these places, and the most common tell of over-enginee…

> Microservices are the right solution for certain problems

Just one problem, actually: Conway's law.

When your organization needs to operate like the macro economy, where independent groups provide services for each other, then you are going to see the same structure found in the macro economy mirrored in the microcosm of that single organization. Hence the name microservices. Same as services, except not across business lines.

At Google scale you have no choice but to have an internal economy, but trying to build an entire economy inside a small business with less activity than a personal blog is crazy.

Re: Perfection is not over-engineering

#54

Post by 0x20cowboy »

> I believe a perfect solution exists.

That is incorrect when dealing in the real world with many different humans using a complex system. I’ve heard other people say this, and it always confuses me how it is not self evident. Human interaction is not a maths equation. There are too many random variables.

Re: Perfection is not over-engineering

#56

Post by close04 »

axus wrote: post #52
__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 fixing bugs and backwards compatibility the enemy of shoveling out more features

The expression is “the enemy of good” not “the enemy if something” so in the end it’s about defining “good”. It varies with context. What’s good, move fast and break things or go slow and considerate? Is risking bugs worth it to launch a feature? How important is that feature? How important is it to have it now vs. later? And how do you reconcile it when what’s good for you is bad for me?

Re: Perfection is not over-engineering

#57

Post by moritzwarhier »

close04 wrote: post #56
axus wrote: post #52

Earlier quoted context omitted.

Let's not make fixing bugs and backwards compatibility the enemy of shoveling out more features

The expression is “the enemy of good ” not “the enemy if something” so in the end it’s about defining “good”. It varies with context. What’s good, move fast and break things or go slow and considerate? Is risking bugs worth it to launch a feature? How important is that feature? How important is it to have it now vs. later? And how do you reconcile it when what’s good for you is bad for me?

It's just the same about the definition of "perfect".

Fixing critical bugs is not perfectionism. Fixing low-impact bugs by making high-risk, well-intentioned changes might be.

Re: Perfection is not over-engineering

#59

Post by smaudet »

dasil003 wrote: post #30
__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…

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 - selling data is not something that a tool can (by itself) provide (unless you accept virtual or test data).

Attaching a product mindset to a tool then becomes a matter of complication/value reduction, vs a product mindset to a consumable, like a game, or dataset, where the value is at least constant, if not growing over time.

I.e., I'm not sure I agree that the "enshittification cycle" is the variable here - even in the age of AI the value e.g. of a stock image service is constant or growing, even if the LLM generation process dilutes the market.

Re: Perfection is not over-engineering

#60

Post by Ekaros »

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.
Post reply on HN