The Most Important Rule
Always Be Shipping
There’s one constant in making code.
Always Be Shipping.
It’s really that simple, and yet it’s the hardest part about making good code.
It’s too easy to get ahead of yourself and stop making things. In fact, it seems like it’s so easy to forget that you need to ship that a whole Agile industry sprung up around a simple manifesto which as its first principle:
Our highest priority is to satisfy the customer through continuous delivery of valuable software.
My version is “Always Be shipping,” because it’s pithy and a bit goofy.
Don’t get Ahead of yourself
Getting stuff done is the name of the game, but often we’re excited about the possibility and intoxicated by the fantasy of creating the perfect piece of software. This is the reminder from the first principle hidden in the third principle:
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
So, ship the smallest possible thing. Large things and complex systems must take time because we’ve learned and seen that they take time.
Don’t Fall Behind
The easiest part of coding is writing the code down. The hardest is usually a contest between distributing deliverables, getting the actual requirements, and making and keeping deadlines.
The easiest way to really make shipping hard is to make the estimated deliveries long.
I think of it this way: if you’re making something that takes about 2 days to complete then if you completely miss the mark and need 5 times more time, you’re now at 10 days. In the realm of estimates, it’s basically 1 more week. In contrast, if you’re looking at something that takes 1 month to create, the same margin of error balloons to almost half a year.
Note, that I assume that most missed estimates scale and balloon proportionately to the problem. I usually find this is the case because I usually plan around the “happy path,” or at least close to it. If you don’t find this to be the case (i.e. if you always miss estimates by some constant) then I’d love to pick your brain.
Don’t fall behind by adding in generous buffers (I tend to use 2.5x what my heart tells me, YMMV), and keeping cycle times low when possible, “a preference to the shorter timescale,” if you’ll recall.
Make things that People Use
It’s not necessary per se and you can cheat if you’re the only person that uses it, but it’s good to keep in mind who will be using your software when you’re done.
I’m putting this reminder in for myself too - it’s one of the worst feelings when you’ve spent a lot of time and effort making something that needs to get thrown in the garbage. I’ve had it happen to me, and the deflated feeling you get when the project you’ve been working on for 4 months gets canned is not great.
Sometimes, you do need to make things that need to be thrown away immediately. Prototyping is an important learning tool for healthy development, but we don’t ship prototypes! Or, at least we pray we don’t. When making a prototype it’s important to work on teams that you can trust to join you in throwing things away. There’s a whole new post in the making about getting rid of code and how it’s generally good… but that is for another post.
The other side the failure coin is unshippable code. Unshippable code is the same as no code - you may as well have done anything else, and “Works on my machine” is a sad echo to a failed ship. There was a recent video that popped up on r/programming about the absolute state of shipping and the complexities of software. If you haven’t seen check it here.
(TLDW) The talk brings points out that shipping is so hard that people invented Docker. Small addendum, I don’t really agree with everything in this talk, but it’s interesting nonetheless.
Ship things people use, and ship things that people will want to use.
Ship Where They are
I feel like I never really watched Field of Dreams but one thing that I had to get out of my head was:
If you build it, they will come
With software this couldn’t be farther from the truth. This is probably the hardest part about shipping.
If you build it, chances are someone else has too. Right around the corner is going to be another similar project and a similar passion to yours. Chances are you’re not the best either. But that’s really beside the point - Steve Jobs proved you didn’t have to be the best to be the most successful!
I’m (obviously) no fan of Apple, but it’s undeniable that the iPhone is king, and probably will be for a long time. Marketing aside, the iPhone’s original success was not that it was the best product ever, or even that it was original. Its success was that it shipped successfully. I cherry-picked this NBC article to show my point, but almost nothing about the iPhone was new, and I’d argue that undoubtedly someone would have created Apple’s earth-shattering invention. Star Trek: the Next Generation guessed that touch screens and handheld data pads would be the way of the 24th century all the way back in the 90s.
All this to say, the iPhone shipped, and it shipped well. To support the compilation of several new technologies, they also provided slick software and more features that people wanted. It leads into a bit of an infamous quote:
It’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them.
The big thing and maybe one of the most difficult facets of “Always Be Shipping” is that shipping means that people can use it, and get to it, and they know it exists. Making good software isn’t the end of shipping: it’s the beginning; your users need to know it’s there.
Only then, will they come.
Finally, Always Be Shipping
I’ve spent a whole article repeating the mantra
Always Be Shipping
But if it were simple I wouldn’t need to remind myself. In fact, it’s ironic that I’m making this article after a rather long hiatus!
I didn’t mention anything about CI/CD, sprints, or tooling - those are all helpful tools for shipping, but those things aren’t shipping. I’ve tried to write out all the things that are shipping, and how to do it successfully, at least from what I’ve seen.
Here are a few other fine articles about shipping, I’ll try and update this page with more info as I find it.