Comment by klodolph | Hacker News Reader

Comment by klodolph | Hacker News Reader

I see this a lot when people are looking for some library / framework / programming language / game engine. You keep adding requirements and assume that you can spend some additional time evaluating alternatives to make up for the longer list of requirements you have. Reality is, there are often only a few serious alternatives in the first place. Adding more and more requirements to your search is, in some way, a stubborn refusal to prioritize among those requirements. Prioritization doesn’t just mean affirming that some of your priorities are important, it means acknowledging that some of your priorities are unimportant and can be discarded.

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.

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...

Because you're not deciding what you care about, instead of a straight bakeoff, each option is in multiple two-way fights where only its strengths or weaknesses over a particular other option are considered relevant. Option 1 beats option 2, beats option 3, beats option 1...

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.

If you're not comfortable with them, you have learned something about your true priorities.

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.

What kind of problem spaces need so much trial and error to understand?

https://xkcd.com/592/

What does this comic have to do with the topic?

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.

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.

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.

Reply on news.ycombinator.com