Hackers and Painters

The ever reliable Paul Graham has an essay (originally a speech) comparing Hackers to Painters. Interesting reading, as Graham always has. My favorite bit:

Only a small percentage of hackers can actually design software, and it’s hard for the people running a company to pick these out. So instead of entrusting the future of the software to one brilliant hacker, most companies set things up so that it is designed by committee, and the hackers merely implement the design.

If you want to make money at some point, remember this, because this is one of the reasons startups win. Big companies want to decrease the standard deviation of design outcomes because they want to avoid disasters. But when you damp oscillations, you lose the high points as well as the low. This is not a problem for big companies, because they don’t win by making great products. Big companies win by sucking less than other big companies.

This is just a side point of his larger and very interesting talk, but it is one near and dear to my heart. I’m conflicted, because I believe it is entirely possible for a development group to have their shit together, to be organized and clicking, and to deliver without letting the bureacracy and process stifle the results. I know, I’ve done it. In the case of me and my team, it helped that we were isolated physically from the company headquarters, and on a product path off the main line of the company. That enabled us the breathing room to do something fantastic, and later on resulted in all of us getting laid off when the main company had no idea what to do with the stuff we built them. You live by the sword, you die by the sword I guess. Anyway, read the whole talk. It is great and it helps pump me up for both the rigorous and the woo-woo creative part of what I do.