I'm not sure I like the title. It seems to be clumsily conflating casino gambling with bad software practices. The first is not a good metaphor for the latter, especially since most of those premature abstractions come out of FUD and attempted risk aversion. (We won't be able to scale if we don't use design patterns!)
However, the insights into premature abstraction are good.
I strongly, strongly disagree with the idea that you should only build products where you're the end user. There are many interesting problem domains where the end users aren't suited towards building the solution.
My company does Machine Learning for Sales. There aren't a huge number of people who can do both programming and statistics well. Add Sales to that skillset and there are, what, 5 people in the world who can do all 3? The odds of finding a sales person who wants a predictive sales tool and has the capability and interest to write it are vanishingly small.
For a consumer-oriented example look at Coursera or other MOOCs. Andrew Ng is not a Coursera user (i.e. student.) He understands students, and that's enough-MOOCs provides enormous value because they solve an important problem. Students would have had a much harder time creating Coursera than Ng.
I strongly, strongly disagree with the idea that you should only build products where you're the end user.
I as well. Most software sucks because the people building it aren't motivated. Building for oneself is one source of motivation, but it's myopic to assume that it's the only source of motivation that works.
Fair. I think the analogy goes this far: in gambling, there's "beginner's luck", which is actually selection bias in favor of people who have early luck. (Beginners with shitty luck stop playing and therefore don't "begin".) In software, there's the tyranny of past success: the tendency to fight the last war.
He's comparing gambling (e.g. risk-seeking) with software development practices that are more often than not an incompetent expression of risk-aversion.
However, the insights into premature abstraction are good.
Here's a beautiful, and relevant, essay from Steve Yegge: http://steve-yegge.blogspot.com/2008/08/business-requirement...