Hacker News new | past | comments | ask | show | jobs | submit login

Maybe the OP needs to clarify what type of "problems" exactly he is referring to..the examples he gives point to problems requiring significant engineering efforts, which is very different from the examples you note above.

The difference is how well defined the problem is. Clojure, Datomic, and Git all benefited from predecessors that were used extensively and had definable shortcomings with a clear enough technical solution.

Yes. I would say people or teams which developed solutions that look as if they "just appeared out of careful consideration" did not -- they simply learned from others and took in that prior world knowledge. The solution space for most problems is not "one global optimum" -- use cases have to be taken into account (which is why great projects like Clojure are not used for everything).

I would go so far to say there isn't actually a dichotomy here -- you should be swapping between launching something with a hypothesis (in lean mode) then gathering feedback and considering alternatives as you are proven correct/incorrect (hammock mode). I think Galls Law [1] is also relevant here:

"A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system."

If all you do is think and think, then you open yourself to mis-timing a solution, feature and scope creep, and risking "unknown unknowns". If all you do is launch and incrementally iterate you'll be stuck solving very narrow problems.

[1] https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact