We live in a pretty amazing world. Right now, I have on my desk several devices with which I can communicate with people nearly anywhere on the globe. I use one of those devices every day for several hours at a time, both for communication with others and to create things. The money I earn doing that is automatically put into my checking account, and I can spend it on groceries with a little plastic card that I carry in my wallet. I can even order food online and have it delivered directly to my house, for a very modest charge, that is nearly always a better choice (price-wise, not nutrition-wise) than driving down the street to get the food (at least for pizza, grocery delivery isn’t quite here yet, but will be). I could, right now (well, if I had renewed my passport) be in India, Iceland, or Argentina within a day. In short, we live in truly amazing times and are capable of things our ancestors would have never dreamed of.

It’s easy in the midst of all this to forget that things don’t have to be perfect from the outset. That code that lets me communicate with someone on the other side of the world breaks on occasion, as do bank transfers, online food orders, and even airplanes. While the above has to have a tremendous level of fault tolerance, simply because of the number of people relying on it, the same is not true for everything. You can build a game, write a book (or a blog post) and it doesn’t have to be perfect to be useful. If it’s good enough, it’s good enough to revisit and refine too. That’s probably the easiest thing to lose sight of, especially when working with software (hardware is another matter). Not everything has to be perfect out the gate, especially not when iteration on a design is as easy and inexpensive as it currently is. Our environment is not that of aeronautics engineers – nobody (probably) dies when one of your prototypes fails, especially when it isn’t even out in production.

It’s really easy to get intimidated. There are some absolutely phenomenal engineers out there these days, producing polished, wonderful products that improve a lot of people’s lives. It’s very difficult, unless you consciously think about it, to realize just how many things they produced before whatever they are showing you were absolute crap or even how many versions of the same thing they produced before they finally got this one right. Yet they were necessary steps on the evolution of a design. It’s trivially easy if you aren’t careful to compare someone else’s apex to your beginnings. The good thing is, pretty much nobody ever goes on the golf course their first time with Tiger Woods. It’s ok to suck at what you are trying to do – it’s a natural and necessary part of growth. Even Tiger was once bad at golf.

I remember watching old war movies with my grandfather, when we could get away with it. Every so often you’d hear the phrase “Ready, aim, fire!” when a line of soldiers was practicing before being sent out into the field. This is how so many people seem to want to approach doing big things that change their lives. The trouble is, it’s real easy to stuck on “Aim” for the rest of your days. The above phrase works great when you are doing target practice and are surrounded by friends, but it’s no metaphor for actually getting things done. It’s like General Patton said, “A good plan violently executed now is better than a perfect plan executed next week.”. Get to the point where you can move forward, then do that. Most of life is not aeronautics or civil engineering; most things can be adjusted as you go. You’ll find that plans that take too long to make are often disrupted by people who planned just enough to get moving.

So, to circle back around, how is this relevant for programmers? Well, we’ve kind of been learning this over the past decade and a half haven’t we? The above is one of the reasons agile works as well as it does. Starting out, we have a large scope of work to do, and don’t even really have a good idea of what the users want (at least, not enough of an idea to go into seclusion for six months and build it without further communication). Few and far, far between are the projects with complete, unchanging specifications from the outset. Most of the time, you have enough to get started, and often little more than that. But we make it work by getting it out there, getting feedback, and then quickly iterating. The result tends to be better, cheaper, and more in line with what the user actually wants than it would have been had it all started with the perfect plan.

I know quite a few developers that are nursing product ideas, some of which they’ve had in mind for a decade or more. Some of them have loads of mockups, large chunks of text for specifications, and even some decent market research. But they are still sitting on them. Things that could improve the lives of people around them (or at least give them some entertainment) are sitting there, not being developed and never having a user look at them. I’m encouraging you, if you have one of those projects, get it out there. Get a minimum viable product built, and get it out in front of some people who might want to use it. Your new product probably will stink right out the gate. It’ll have bugs. It’ll have features that are missing. Your marketing will be crap and your help system will be rubbish. But you can fix those. But until and unless you get it in front of users, you don’t really know what those bugs and features are. It’s often easier to change direction once you’re actually moving. So…Move.

(note, I just noticed there is a book of the same name as this post on Amazon. It looks to say much of what I’m saying here. I’d love to hear from readers if anyone has read it. I kept the title of my post the same, but didn’t get it from there. It fits though. Really well.)