Anything is Better than Nothing or Random

I read a set of posts recently which threaded together in my thoughts as motivating a startup. Firstly to the posts, which are as follows:

• The Young Man's Business Model: Contrasting naive and informed problem solving, specifically in the context of development work, with interesting anecdotes.
  
• On Leaving Google: Comments from an engineering regarding the good times had at Google, and an overview of his personal reasons for leaving to do start-ups.
  
• Rails Is A Ghetto: A massive rant about the personal and resultant technical problems with the core ruby on rails team.
  
• Creatively Speaking Interview: (reddit co-founder Alexis Ohanian) Commenting on the founding of the reddit social news web site.
  
• The end of Moswer: A personal account of a startup idea for the mobile web that was pushed for a year and ultimately failed to gain traction, and ran out of money.
  

I took away a lot from this set, although I'll try and articulate the highlights.

The attitude of the hacking-startup culture promotes user-centric results over everything, which is exactly what you want addressing considering hard problems with the web. The reason is obvious and stamped into the title of this post: some result, no matter how crashy, buggy, or slopping is generally better than no result, or the first pass which is likely a random result.

This was reinforced for me by the young businessmans model approach which was basically a re-phrasing of 'quick an dirty', the naivety of which is contrasted with the informed old man approach. The author advocates considering both approaches before just hacking because he has "been there and done that". I would give the same retrospective advice to those considering starting a PhD (do x! do y! don't do it!), when the point of the exercise is the apprenticeship nature of the process.

Both the rails rant and the reddit interview provided insight into the crashy, buggy, and generally crappy nature of the early released versions of rails (crashing a lot, massive memory leaks) and reddit (sleeping with the laptop). These cases are important because both products are successful in their respective fields (web frameworks, social news), although were hacked into existence from a generally naive and uninformed position (of varying degrees, naturally). This is an extreme of worse is better, where nothing is worse and crappy product is workable. This, to me, is the core of the Graham 'just hack' methodology.

The leaving Google story links into the perspective as the alternative. You can join one of the big guys and be trained to do things properly, to rapidly become the "old man" in the way you think and execute projects. The work will be solid and interesting, although as pointed out by the author, your passion and responsibility are bounded by someone else's conservative (for the shareholders) vision. This links into the Mowser case where although the founder is broke, in debt, and the company a "failure", he is still proud and willing the to give startup thing another crack.

Ultimately, these cases solidified my perspective that the continuous development (agile) of a perpetually wrong (beta) product is the way I want to take on hard problems. Using passion and hard work, from a naive and generally uninformed perspective that ultimately result in promoting risky behaviour, e.g. things committed businesses simply cannot or will not do.