Just Do It

In Paul Graham’s essay Made in USA, he writes about America’s tendencies towards design.

Americans are good at some things and bad at others. We’re good at making movies and software, and bad at making cars and cities. And I think we may be good at what we’re good at for the same reason we’re bad at what we’re bad at. We’re impatient. In America, if you want to do something, you don’t worry that it might come out badly, or upset delicate social balances, or that people might think you’re getting above yourself. If you want to do something, as Nike says, just do it.

It’s amazing how well the “Just Do It” marketing line fits America (the only other tagline that works as well is EA Sports’ “If it’s in the game, it’s in the game” line), and Graham is certainly right about how that affects programmers. I’ve noticed that there are really two different types of programmers: people who look stuff up, and people who just try it to see if it works. People ask me questions about HTML or CSS all the time. Sometimes I know the answer, sometimes I dont, but most of the time my response is “Have you tried it to see what happens?” HTML is pretty simple, and it’s easy to test out various concepts. There’s no reason not to, and I’ll also note that trying it is also the best way to learn. I’m reminded of this design parable about a ceramics class:

The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot -albeit a perfect one – to get an “A”. Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes – the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

There are several interesting things about this. First, as Graham notes in his essay, good craftsmanship means working fast and iterating your design. Second, failure isn’t a bad thing in this story. In fact, failure is a necessary component of success. In such a scenario, people who work fast and iterate do much better than people who meticulously plan their designs. As Graham belabors in his essay, this works for some things, not not others.

Of course, not all American designs are bad, and Graham mentions the obvious exception:

Apple is an interesting counterexample to the general American trend. If you want to buy a nice CD player, you’ll probably buy a Japanese one. But if you want to buy an MP3 player, you’ll probably buy an iPod. What happened? Why doesn’t Sony dominate MP3 players?

It’s because Apple is obsessed with good design (“Or more precisely, their CEO is.”) Interestingly, I think one of the reasons the iPod is so successful is that Apple understands the paradox of choice really well. The iPod isn’t and has never really been the leader in terms of features or functionality. But it does what it does extremely well, and I think that’s partly because the iPod is actually quite simple. If you loaded it up with all sorts of extra features, there’s no way you’d be able to keep the simplicity of the interface, and that would make it harder to use, and much less attactive.

In the end, I don’t know that I agree with everything in Graham’s essay, but his stuff is always worth reading.

4 thoughts on “Just Do It”

  1. There’s definitely something to be said for the experience one can gain from failure. At least ideally. Some people never learn from their mistakes. I remember reading a while ago (maybe here?) that companies will sometimes look for executives who have a failed venture on their resume with the idea that they’ll have learnt from their mistakes there and not make them again. There’s too much to gain from experience not to need it to some degree to get something right. There’s plenty to gain from researching what others have learnt but there’s a feel for things you can get that isn’t going to transfer if all you’re doing is research.

  2. Indeed, though one of the points I didn’t really make that I wanted to is that certain things just can’t work that way. When you’re designing, say, an airplane, failure is not an option. Yes, I’d hope we’d learn from such failures, but once human lives are involved, you really can’t mess around. Quick iterations aren’t possible with stuff like airplanes or elevators, etc… Which is kinda the point that Graham was making. However, in looser systems like programming or artistic endeavors, that sort of iteration is possible and perhaps even necessary to achieve greatness…

  3. Ahaha, yes, anything with lives involved is definitely not a casual trial-and-error situation. And certainly analysis without experience is still important in any situation, although especially so in ones with little to no room for error.

  4. To some extent, though, we still try to work out ways to do trial and error, even in those kinds of things. Automotive test labs go to great expense to create realistic crash simulations, and the airplane industry use computer and wind-tunnel simulations to try to work out designs. I was watching a special on stealth aircraft, and it was pretty interesting- you could definitely see the try and try again mentality at work there, as they would create a design, try it, watch it crash, and try again. I think that the key there was that they were willing to invest money in testing and iteration before they put real lives on the line- unlike something like, say, the M-16, where many of the failures and problems were only discovered after the rifle was in production and in the hands of soldiers. It was at that point that they began iteration and refinement. Kind of too late, though, since design flaws and problems were already costing lives.

Comments are closed.