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 onwe 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 didnt 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 wont win, because its too simple. It wont impress the judges. But at least we wont be embarrassed: well have a working program.
So I wrote a little program that wasnt 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.
Butyou can see it comingwe did win. Someone else from my school accepted the award on my behalf. I still have it.
Lesson? Shipping is important.
Its 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 doesnt ship, it doesnt exist.
I bring this up because I hear from people and read on weblogs about software thats pretty cool but that never gets done. It doesnt make it out into the world. And I often wish I could transfer some kind of magical shipping-energy over to the developer.
I dont know why these projects, some of them in quite advanced stages, dont ship. I know what I do: I myself dont 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 youre a software developer, you may have no idea how much of software development is just about all the little details. Its housekeeping. It can be overwhelming if youre 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 theres a terrible bug that doesnt appear, despite all the testing, until right after its released? What if you made the wrong decisions about bug x and feature y?
What you do is just do the best you canand 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. Its not just that shipping is importantI 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 doesnt mean I dont make mistakesI have and I will. But I think this self-trust is important to shipping software.
(An important point though is that self-trust doesnt mean dont listen to other people. The opposite is true. You want as much feedback as possible. The buck stops with you, though.) [inessential.com]