Good enough is good enough (2013) | Hacker News Reader

Good enough is good enough (2013)

ep2013.europython.eu

65 pointshypertexthero29 comments

I think a corollary to the problem of seeking perfection is the notion that there is always a global optimum and that we must be seeking it: a kind of fallacy of the One True Way™. Implicit belief in One True Way™ shows up in many places, like the adoption of "best practices", rather than "preferred practices", or merely conventions. Also in the undertone of many discussions that assume that if there are two solutions to a problem, then (at least) one must be suboptimal.

The concept that I have started leaning on in development is "satisficing"[0], i.e. finding the first solution that satisfies some criteria for acceptability. My new (tacit) motto is "satisfice first, then only optimize if needed."

[0] https://en.wikipedia.org/wiki/Satisficing

Two significant overarching challenges I’ve had throughout my career are over engineering and analysis paralysis. Simple things can get spun from days to weeks, and occasionally I have gotten so anxious about edge cases and potential scale, reliability, or performance concerns that I deadlock and can’t get anything done. The advice is to not let perfect be the enemy of good. On the other hand, I think overvaluing expediency is bad craftsmanship.

I’ve found it worthwhile to first train yourself or your team to detect thrashing or deadlocks. This can be as simple as leveraging standups to hold each other accountable when it seems we’re lagging, to an individual tool where you set small, achievable goals for the day and regularly check in where you answer the questions “have I made progress towards these goals?” and “will I be able to finish these goals today?” where an answer of no to either question means you have fallen behind or are in danger of it.

When necessary activate a “get back on track” checklist:

- Does the thing holding me up align with the goal and requirements?

- Is there significant risk attached to the concern, e.g. harm to the user or business, jeopardizes the goal or requirements, legal or ethical concerns?

- Am I unable to mitigate the risk with workarounds, guide rails, quarantine, etc?

- Am I unable to iterate on this e.g. mitigate if possible and fully resolve later but before larger release?

- Can a quick pivot be made to address the issue without jeopardizing your deadlines?

If the answer to any is no, either throw it in the backlog or drop it entirely if it does not have tangible value to the user or stakeholder. If yes, reformulate a plan and reset upstream expectations.

I think this is something most people tend to do instinctively and without ceremony, but can be challenging for less experienced developers, perfectionists, stubborn folks, or people with ADHD.

Good advice :)

Most of the "temporary fixes" to my hobbyist projects are good enough and stay as the implemented solution for over a decade. Nobody gets harmed or even dies if they break, which might be the most important criteria for not settling with "it's good enough".

There is a Russian saying "There is nothing more permanent than a temporary solution."

I think this sentiment only applies to certain products. A software like Slack can get away with being good enough. Self-driving softwares like Tesla's FSD? Not so much. There are certain engineering solutions that aren't viable without being perfect. People expect them to be perfect.

Here's a physical engineering secret: all things are built to be "good enough", all things are a trade-off, all things have requirements they must fulfill. The products and cars you buy all are built with tolerances. Your hot dogs can only contain so many rat feces; they aren't perfect.

From a builder's perspective, yeah, everything is built with a tolerance. It's just that many users are not aware of those requirements, or lack thereof. Would you feel comfortable eating a hot dog knowing it contains any rat feces?

I already do, every time I eat a hotdog.

If that's the case, then Tesla has a certain number of children their FSD solution can run over every year, below which its cheaper to settle with the parents out of court instead of improving their FSD solution.

This is a classic ethical dilemma. Self-driving cars will kill some amount of people via malfunctions, accidents, etc. Some amount will be children. Should we ban the development of the technology? What if it only killed 1 child? What about 10? What about 100? How many dead children is the benefit of self-driving cars worth?

The apocryphal "a delayed game is eventually good" quote seems relevant here. SaaS users tend to be more forgiving of iterative improvements than gamers are, to pick just one example.

SaaS users are going for the utility, whereas gamers are going for the immersive experience. The fault tolerance are different for those two use cases.

Yeah but I do like that Nintendo for the most part lives that philosophy. Recent example I came across was Mario Odyssey. It is 7 years old, never had a patch because it was just considered done. Very cool to see.

I'd like to see some qualification of "Good enough", "Good enough for what exactly?" - what priority/stakeholder/scenario are you using for deciding when it's "good enough"?

Is it good enough to enable users to get their work done?

Is it good enough to make a profit?

Is it good enough to satisfy investors?

Those all lead to quite different outcomes.

I worked on a system that was good enough, then the requirements changed, becoming far more complex; suddenly it was almost impossible to keep improving and updating the codebase without 10 bugs appearing in production (and not in tests). Good enough may be good enough for the time being, in the long run who knows

Years ago some big-name VC or another tweeted "Good enough sucks" and got a ton of attention and praise for their keen insight and commitment to quality. I remember rolling my eyes and thinking, "If it sucks, it wasn't good enough".

I am not endorsing or defending that pithy saying but maybe they meant ....

"What's good enough in the short term sucks in the long term"

"What's good enough in a narrow view sucks in the big picture"

Trying to think of an analogy: if I settle for just "good enough" on a day-to-day basis and don't push myself to go beyond my current skills / comfort zone regularly ... maybe I will regret not pursuing bigger things when I look back at my career 5-10 years down the line.

In some senses that is exactly the kind of FOMO and perfectionism that burns out people. After being in that mode myself for almost two decades I am now consciously stopping myself -- almost daily -- from pushing myself too much. You could say I have become complacent or apathetic too.

engineering is the science of good enough.

life is the art of good enough.

Is there really conflict here? It seems like good enough is an obvious first or second step, but over time experiences accumulate to the point where one more iteration of good enough comes to approximate perfection.

Close enough to perfection. Good enough.

Alex Martelli's talks are always worth watching.

Boeing joined the chat...

I get the gist and agree to some degree, but two stories down from this one is hackers that stole UHG data...

Was that good enough? Someone thought so at the time.

I think there always needs to be a distinction between "underdeveloped and unfinished" and "broken and insecure".

I don't care if v0.1 is still lacking features and the GUI is wonky. I'm usually fine with this being called "good enough".

I care a lot if v0.1 crashes on launch, half the features in the release notes don't work (or even exist), and it leaks my passwords as plaintext. As a user this is never "good enough".

In most conversations those both get lumped together in the move-fast-and-break-things mindset. Though to be fair, the original article is largely talking about the former.

The article may be talking about the former, but plenty of people will read it as the latter. (Though perhaps not to that extreme.)

I would certainly consider a well designed but feature incomplete product as perfect and good enough. Chasing perfection doesn't mean being everything to everyone. It simply means doing the best job possible.

How do you know they didn't think it was perfect and needed no improvement?

In this day and age of perfectionism, being good enough to push out half-baked software is definitely cash-grab, especially when it cones to gaming and pre-orders.

Reply on news.ycombinator.com