Re:Nirvana Fallacy
by austin-cheney on Thursday May 25, 2023 @05:29PM
(#36076499)
Due to libraries and frameworks I most typically see the inverse of this fallacy. A team claims to want something amazingly ideal and yet easily feasible, but then reject the premise outright if they cannot execute it in their favorite library or framework in 30 seconds or less.
This hits home. Manytime have I come to appreciate a library or technology only after delusionally attempting to create a 'better' version. Mid attempt I actually start to understand the problem space, at which point I humbly and thankfully start depending on said library or technology.
Re:Nirvana Fallacy
by MichaelZuo on Thursday May 25, 2023 @06:45PM
(#36077378)
What kind of problem spaces need so much trial and error to understand?
Re:Nirvana Fallacy
by MichaelZuo on Thursday May 25, 2023 @07:01PM
(#36077549)
What does this comic have to do with the topic?
Re:Nirvana Fallacy
by sethammons on Thursday May 25, 2023 @08:20PM
(#36078203)
Did you read the alt text?
That looking at almost any problem and thinking 'this seems simple?' is generally an indication that you have MASSIVELY underestimated something.
In other words, that by asking the question 'What kind of problem spaces need so much trial and error to understand?' you are betraying a sort of charming naiveté.
Yes, I very much see myself in this. Though rather than humbly depending on the library, I tend to wander off in disinterest. I realize that my motivation came from saving the world with a supposedly better solution, and I didn't actually care that much about solving the problem in the first place.
It hits home when you realize people were saying 90% of software projects were failure.
People wanted perfect solutions in one go. Everyone was blaming software developers.
If one expects only perfect outcomes then it is easy to get high fail rate.
Another related pattern: rock-paper-scissors comparisons.
Say we're looking to choose a library.
A - Let's use FooLib. It seems to be the most widely used.
B - Nah, FooLib's kind of outdated. We should use NeoFoo, it's more modern.
A - Well plain old libfoo is way faster.
B - But FooLib has a way friendlier API...
Prioritize your requirements. Try out sentences of these forms:
I would be okay with lower performance if the API is easier to use.
I would prefer a fast implementation of this even if it were unsupported.
Related is the assumption that any custom-built library you write is going to beat an existing, well-known library that doesn’t exactly match your needs. It’s easy to come up with a list of problems with existing libraries, but your theoretical custom-built library can be perfect, because you’re not imagining that it has any serious bugs or design flaws. You end up building your own solution and, in the process, rediscover why the existing library was built the way it is.