Setting a Goal. The flag in the distance.

I just thought I would throw my 2 cents into the popular theme of setting goals in the new year.

I think we are wrong to think of goals as an end game. I don't think that achieving a goal has much value. It is the process of getting it that arms you to handle larger challenges in the future.

Don't get me wrong, I'm not against the idea of setting goals for the new year. In fact, I'm all for setting goals any time of year. I just think that we need to focus on why we are trying to achieve our goals, and how we plan to get there. And then, we should reserve the right to change our minds about how we plan to get there, while the goal itself remains a flagpole stuck in the sand way off in the distance, reminding us of which direction we need to ultimately go in.

Some of the tactics we use to get to that flag may not work, and we'll need to revise them. Sometimes we may need to cross a river to get there, and our plans will need to be revised again. This is an important and valuable process.

The flag in the sand keeps us going, but it is the problems we encounter along the way to reach that flag that really make us who we are.

John F. Kennedy understood this when he decided that the nation needed a rally in the middle of the cold war. He made the point well during his "Moon" speech at Rice University. If you have not listened to the speech, you should Google it and listen to the whole thing.

"We choose to go to the moon. We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win."

Your specification documents need to be driven deep into the woods and "eliminated."

Spec docs are just an excuse to pretend that you are doing something important. Nobody really needs them, because all that really matters is that the code ships and people like it enough to use it. Developers who get stuff done don't write spec docs. Sure, they take part in the flame wars on the open standards mailing lists, and they might even write a spec after implementing it, but while all this is going on, the developers that really matter are shipping code at the same time.

The worst offenders are the committees of so called "open standards" people posturing in their academic micro environment. And who is impressed? The users? I don't think so. Doug Crockford came up with the JSON standard all by himself. He even joked in a presentation, calling himself "the one man standards body". I think that's the best standards body I've ever heard of.

Go to this link and read it. Its a walking tour of a mailing list where the early web browser developers are kicking around some ideas for what HTML would become. Go there and read it now, and then come back. You'll notice some ideas on there, some good, and some really bad. But you know what else? Marc Andreesen shipped the code for his browser without waiting for everyone else, and it changed the world forever.

You might complain that HTML doesn't really work very well and needs to be thrown away. But, is the big fat pile of steaming poop called HTML5 any better? HTML5 is the camel created by a committee that set out to create a horse.

Dave Winer recently had this to say in a blog post about the OAuth spec:

If you want to get smart about open standards, you have to watch how these things play out in another open thing -- the market. Because it's the market that just as often shapes a standard as it is a standard that shapes the market.

My sentiments exactly Dave.

I think the best strategy is to take the only the good stuff from open specs and then use whatever you can lay your hands on that will create a minimum viable product the fastest. Don't bother with writing a spec, the code is the best spec you could write. So, let's ship some code this year!

Software should be like bicycles.

image by jesse.millan

• The complex machinery of a bicycle is restricted to the absolute minimum needed to get the job done.
• A bicycle is so efficient that physical fitness and wind drag become the most limiting factors of speed.
• A bicycle is a modular machine made of parts that are interchangeable with the parts of other bicycles, even those made by different manufacturers.
• The controls of a bicycle are universally used and understood by almost everyone.
• Bicycles are everywhere! Almost anyone can find one that fits their budget and faithfully serves their purpose.

I think more people should use bicycles for daily transportation, I think drivers should be more respectful of people who ride bicycles on the road.

I also think that software developers need to learn a lesson from bicycle builders. We need more bicycles and fewer aircraft carriers. Yahoo! is getting a lot of grief for Starting! a! Cycling! Team!, but maybe they are on to something?

I've never been able to find bicycle software, (except for my favorite Linux distribution) so I decided to create my own. It is called Kixx and I'm working really hard on it at The Fireworks Project. Someday I hope everyone will use it to be more productive, have more fun, and be able to get more out of the stuff that really matters in life.

I fondly recall the years I spent riding my bike to work through the streets of Boston. Maybe that's a little strange, but too often we take simple things like that for granted.

(edit: I would like to add 37Signals as a bicycle software maker: http://37signals.com/)