Ship it


I had a conversation the other day with some colleagues (all of whom have a demonstrated ability to ship software) about how doing so is inherently a process of sacrificing your ideals. Projects that either have unrealistic notions of perfection or no pressure to ship usually don’t ship.

While developers continually bitch about unrealistic dates (I’ve done my share), having an end date is a really wonderful forcing function to shipping software. Having an end date means that you must make choices: about what should and should not be in the software, what bugs should and should not be fixed, etc. Pretty much any software worth using is complicated enough that it will have bugs (regardless of whatever extreme agile scrum TDD blah blah blah process you’re using).

In my experience, great software engineers have two things:

  1. An idealistic desire to build perfect software
  2. The ability to sell out #1 so you can actually ship something

Comparing and contrasting the building of software to the building of bridges is fashionable and I generally loathe that sort of thing. But if I were going to do so, I’d want to say that bridge engineering is mostly about #1 and not so much about #2.

“Hey guys, we’re running a bit late on this whole bridge thing. Do we really need that bit in the middle? Maybe we can do that in a service pack or something.”

Of course, I’ve never built a bridge and I’m pretty sure this is full of crap, but what I’m trying to say is on the continuum of engineering compromises, software development is off the freaking chart compared to more traditional forms of building stuff.

On one hand, you want to have an ideal, a perfect thing you really want to build. And this is either pure art or pure engineering depending on whether you are building something for use or not. But on the other hand, you want someone to use your software, because writing software that no one uses is lame.

I would say that in my admittedly brief tenure as a developer, the moments where I have seen awesome software engineering are not those where we wrote some really wicked algorithm, but rather those where we sorted through all the crap that could be done or wasn’t quite done and decided the twelve things (of 7 billion possible) we could do that would let us ship something that moves us towards that ideal. It’s not pretty, but I find it immensely satisfying.

Making these choices requires hard choices trading off quality and capability. Doing this badly results in something that ships but fails to be anything people want. Doing it well results in something that people can love if you can make the right trade-offs.


3 Responses to “Ship it”
  1. Franck says:

    Good post. I agree that having a fixed shipping date forced both developers and users to be realistic.

  2. I’ve read about the bridge and architecture analogies in the past and never thought they really fit. Recently I read “The Pragmatic Programmer” (Hunt, Thomas) where the authors compare programming to gardening. This analogy doesn’t fit as well in the planning stages, but I think is appropriate when you look at the activities of a typical programmer. I spent many days in my garden as a kid and despite all my planning I could never predict exactly what my garden would look like, which plants would need to be trimmed or moved, and which plants would die off. I’ve come to believe that programming is more of a craft than an engineering discipline, that good programmers (like good craftsmen) have lots of tools they learn to use over many years (editors, languages, debuggers), and that code often exhibits organic-like growth that can’t be predicted and requires an experienced hand to maintain.

  3. Alex says:

    Yep, the gardening metaphor is pretty good. Weeding == refactoring (or bug fixing maybe). Fertilizer == patterns? Kudzu == feature creep. :) Moles == marketing. You know, that sort of thing.