derek hubbard

think. code. blog.

If We Aren't Focusing on Shipping, Then What the Hell Are We Doing?

I want to ship code. I want to provide value. I’m a coder, and there are not many things I get more satisfaction out of than seeing someone use my code. There are few things more gratifying than watching someone find value in something I produce.

But why do we care so much about shipping?

Someone recently asked me why some developers care so much about shipping. I was speechless at first, and kind of taken aback. I didn’t know how to respond. Doesn’t every developer want to ship code?

After letting this question sit in the back of mind for a couple days, I came to one conclusion: If we don’t care about shipping, then what the hell are we doing? If we don’t care about providing value to customers and delivering awesome software, then why do we come to work each day?

Seriously, it’s a valid question. Sure, it’s fun to learn new technology and build prototypes, but I want to create something that has a purpose. I want to build something useful. And then I want to step back and let someone use it. I want to step back and let someone find value in something I created.

But shipping is hard – maybe initially we have to deal with building out new environments, and then figure out what it means to deploy. And if we want to plan to ship frequently, we have to start tackling complex problems, like how do we upgrade our applications without rebooting the server or how do we deploy new features to “beta customers” without rolling these features to our entire customerbase? These are hard problems. And we should be thinking about them from the very beginning. For me, the Scrum process, as defined by, is the framework for thinking about these complex problems by emphasizing incremental deliveries of done done (not just done, but…) working software.

We know nothing until we ship. As Ryan Cromwell reminded me today, everything we have done so far is an assumption until we’ve shipped it. Every design document and architecture decision made by our team is merely an assumption until validated with actual, working software in a production environment. Shipping exposes our team’s actual strengths and weaknesses instead of our assumed strengths and weaknesses. We are forced to deal with reality instead of fantasy. And the sooner we face this reality, the sooner we will be able to start identifying what new features our organization or customers would like to see next.

Only then can you get the true satisfaction of knowing we are building the right thing. Otherwise, what the hell are we doing?