Today's lesson comes to you courtesy of your local Department of Transportation:

The Utah DOT is spending $6 million on a feasibility study for a bridge across a lake. Meanwhile, the DOT doesn't have enough money to put up traveler information video cameras at dangerous mountain passes and canyons to help motorists make safe driving choices. That $6 million could have easily paid for the cameras, while still leaving money for a reasonable analysis of a bridge feasibility.

In Washington State, budgeted money for a drainage project has been tied up in studies. Meanwhile, recent flooding has wiped out several small cities with damages in the tens of millions, destroying many people's lives. And $16 million is being spent on a rail trail conversion study. That money would be enough to build a new freeway interchange and relieve millions in congestion delay and improved safety today.

John Taber, the author of the article, is professionally involved in exactly these kinds of studies. His opinion?

Heck, I make a living off transportation studies and even I'm saying there's too much study and not enough construction.

It's an easy conceptual trip from building bridges to building software. In software, some developers take up residence on planet architecture, an otherworldly place where software is eternally planned and discussed but never actually constructed. Having endless discussions about software in a conference room or mailing list feels like useful work-- but is it? Until you've produced a working artifact for the rest of the world to experience, have you really done anything?

One of my favorite quotes on this subject comes from Christopher Baus.

Software isn't about methodologies, languages, or even operating systems. It is about working applications. At Adobe I would have learned the art of building massive applications that generate millions of dollars in revenue. Sure, PostScript wasn't the sexiest application, and it was written in old school C, but it performed a significant and useful task that thousands (if not millions) of people relied on to do their job. There could hardly be a better place to learn the skills of building commercial applications, no matter the tools that were employed at the time. I did learn an important lesson at ObjectSpace. A UML diagram can't push 500 pages per minute through a RIP.

There are two types of people in this industry. Talkers and Doers. ObjectSpace was a company of talkers. Adobe is a company of doers. Adobe took in $430 million in revenue last quarter. ObjectSpace is long bankrupt.

So that's what you have to ask yourself: are you a doer, or a talker? Ideally, you'd be a little of both, as I've said many times here. There's certainly value in some discussion and planning on your team. But if you must pick one or the other, try to err on the side that produces useful, working code:

The best way to start an open source project is with code. Working code. Hack away at home on weekends, maybe get a couple of friends to help you out, and don't go public until you have something to show people that does something interesting, and that other people can use to build more interesting stuff on top of. You need this for a bunch of different reasons: it establishes the original contributor's bona fides in the open-source meritocracy, it shortcuts all sorts of damaging debates about coding styles and architecture that can stop a project before it starts, and so on.

Working code attracts people who want to code. Design documents attract people who want to talk about coding.

There's a definite upper bound on the value of pure, theoretical discussion and planning in software. The trick is knowing when you've reached that limit, and how to funnel that effort into producing real code assets instead of letting it dissipate in a harmless puff of hot air.