Was that good enough? Someone thought so at the time.
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 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."
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 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.
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.
"What's good enough in the short term sucks in the long term"
Or
"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.