Image courtesy of flickr.com

When I learned to program computers, it was a very different world than it is today. The biggest difference was that there was no Internet, so there was no such thing as a downloadable patch. Whatever you put on the floppy disk, that’s what the users were stuck with. Release a buggy program, and angry users might never buy from your company again. Think of a new feature you want to add, and it’d have to wait until you released version 2.0 in a couple years.

So programming had to be an organized, methodical process. The programs themselves were more difficult to build, because the languages weren’t that helpful (when you were using a language at all, and not programming in machine code). A program had to be planned in advance and thoroughly bug- and play-tested before it went out the door, which meant most software was created by corporations that had teams of people doing different parts of it. A typical game might have a design team developing the concepts, a programming team writing the code, a graphics team doing the artwork, and a test group playing it and passing problems back to the other groups. All this would be controlled by flowcharts and schedules, and it could take months or years to develop anything.

Though I never learned this stuff in a classroom, that’s the mindset I absorbed where programming is concerned: plan out how all the features will work first, then code it all, then test it until it’s perfect. I don’t do flowcharts, but I try to get the whole thing structured in my head — what features it’ll have, what happens when people click such-and-such, and so on. I assume it all has to be perfect before releasing the software.

That’s the wrong way to program for the web today, though. I think I first started to realize that when I read this article by Paul Graham a couple years ago, but it’s taken a long time to sink in.  He’s talking about starting businesses there, but points 2 and 3 apply to programming just as well, since he’s mostly talking about software startups:

Launch fast.

On the web, if you find a bug after you launch your program, it’s not too late to fix it.  Also, you get feedback from your users online that you couldn’t get before.  So you can let your users tell you what features they want, instead of trying to think of them all yourself.  They’ll think of things you couldn’t, and you’ll avoid wasting time programming features they never ask for.

Let your idea evolve.

With the old method, your idea had to evolve completely first — preferably before you started programming, but definitely before you shipped the product out the door.  Now it can evolve after you release it, and continue indefinitely.  If someone suggests a new feature, or some other new software comes along that yours could take advantage of, it’s never too late to add something.

Another positive aspect of this method is that, every time you add new features, it’s another opportunity to promote your product.  If there’s a feature you can’t decide exactly how to do, save it for version 2.0, and send out another press release when you add it a month or two down the line.

I guess I’m a bit of a perfectionist, because even though I understand all this intellectually, I still find myself wanting to do things the old way — develop the idea first and get all the details worked out, and make sure it’s perfect before letting the world see it.  I have to change that, because it wastes time and leads to projects kicking around in the back of my head and never seeing the light of day.

For inspiration in accepting this new paradigm, I look to Twitter.  It’s probably the most successful new web site of the past few years, and it does practically nothing!  In the beginning, it did even less: let people send phone text messages to groups of people.  They gradually expanded the web interface and added things like lists and hashtags, but it’s still a fairly simple concept.  A lot of the features that have made it more useful, like shortcode URLs, have actually been added by third parties, so the people behind Twitter didn’t have to develop those at all.  Had they followed the old paradigm, they probably would have tried to build all those things into it from the start, and who knows whether it would have ever been released or worked as well.

So my new pledge to myself is that I’m going to start developing the dozen or so web site ideas I’ve got knocking around in my head, and release them as soon as they basically work.  No more trying to get them perfect first, or add every cool feature I can think of before I make the site public.  Just launch, get busy on the next project while waiting for feedback, and fix bugs and add features.  Rinse and repeat.