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.

Comments are closed.