On shipping software
I learned at an early age the importance of shipping software.
My first software award
It was 1982, I was barely a teenager, and I was at a computer fair where young geeks from all over Delaware were competing in a programming contest.
We were paired up at random with other geeks. (Early extreme programming?) Our mission: to write a BASIC program that sorted an array of strings.
Each pair had a computer to work on—we were in a room full of Apple II Plus's (or perhaps Apple IIes). We had a time limit, something like two hours.
I discovered quickly that my co-geek didn’t actually know much about programming, so I just kind of talked to him as I wrote the program.
We faced a big decision right at the start. Should we use the slower, but easier to implement, bubble sort algorithm? My comrade just kind of shrugged and agreed. I laid it on the line: if we do it this way, I said, we won’t win, because it’s too simple. It won’t impress the judges. But at least we won’t be embarrassed: we’ll have a working program.
So I wrote a little program that wasn’t fast but that actually worked to sort an array of strings. After we were finished, I told my Dad I wanted to go home, since there was no way we were going to win. So we left.
But—you can see it coming—we did win. Someone else from my school accepted the award on my behalf. I still have it.
Lesson? Shipping is important.
It’s kind of like what Woody Allen said, “90% of life is just showing up.” Software is the same: it has to “show up” first. If it doesn’t ship, it doesn’t exist.
I bring this up because I hear from people and read on weblogs about software that’s pretty cool but that never gets done. It doesn’t make it out into the world. And I often wish I could transfer some kind of magical shipping-energy over to the developer.
I don’t know why these projects, some of them in quite advanced stages, don’t ship. I know what I do: I myself don’t even conceive of not shipping. Once I have committed to a piece of software, I just keep going.
The brick wall of shipping
I actually picture in my head a weird little scene. I see a big field of grass with a line drawn in it, like a line on a football field. And then I picture a giant brick wall moving forward slowly but steadily toward that line. The line is the shipping mark, and the brick wall is the software. Nothing can stop that wall.
Part of shipping is attention to detail. It can get boring, tracking down and finding all the million little things. (Unless you’re a software developer, you may have no idea how much of software development is just about all the little details. It’s housekeeping. It can be overwhelming if you’re not used to it.)
Another part of shipping is making hard decisions. When do you stop? How do you know if a feature can wait until a later release? How do you know which bugs you can live with and which are deal-stoppers?
And another part of shipping is anxiety. What if there’s a terrible bug that doesn’t appear, despite all the testing, until right after it’s released? What if you made the wrong decisions about bug x and feature y?
What you do is just do the best you can—and when you make mistakes, you deal with them the best you can. You get better at shipping software every time you do it. Experience is your teacher.
Going back to my experience at that computer fair in 1982... I learned another important lesson. It’s not just that shipping is important—I also learned that I could trust myself to look at my resources and the amount of time available and the goal and make a good call. I learned I could trust my judgment. That doesn’t mean I don’t make mistakes—I have and I will. But I think this self-trust is important to shipping software.
(An important point though is that self-trust doesn’t mean don’t listen to other people. The opposite is true. You want as much feedback as possible. The buck stops with you, though.)