How Often Should You Ship?

Back in the floppy-in-a-box days we tried to ship no more than twice a year or so, as it cost money to ship a new version and often we had to charge the customers at least something for it.

For Trapeze and Deltagraph back then we never had to ship any “patch disks” or emergency fixes so the only releases were generally major ones. Our releases had to be of quality to stand on their own for at least 6 months. Most of the time we did not even know who any new buyers were unless they told us.

For the purposes of this post I want to talk mostly about apps, particularly mobile apps since that I what I do today. While shipping these days is easy (even Apple is fairly quick these days) and free, the question of how often is still a valid one.

Looking at the App Store you can see that many companies ship as often as possible, two weeks is common but you see even less then that. Other companies ship more irregularly and some like my employer ship 5-6 times a year at most.

Companies that have a shipping pipeline of two weeks or less often have large staffs and are highly organized so that no developer does a lot of actual work, changes are generally small, and anything more complex are worked on in separate branches with frequent merges to keep up. The emphasis has to be on never breaking anything since that would gum up the pipeline. By having a large staff making many small changes with lots of testing support—automated is basically the only way—you can hope to keep the regular pace up.

The question I have is why is such a fast pace even required? Sure you can talk about keeping up with the market and trying to get the best product for your customers, but what of the cost? If you have dozens or even hundreds of mobile engineers (Facebook and Uber come to mind) constantly churning out new releases in a complex dance of branches, is shipping every week or every two weeks really worth the cost?

Having worked on travel apps a couple of jobs ago, our customers for the most part used our apps to book travel a couple times a year, sometimes they might browse a few more times. What would shipping every two weeks do for them? The odds are that most of our customers might run 10% of our releases and thus rarely even take advantage of anything we churned out. It’s doubtful they would even notice anything new or fixed. Not every app is used every day.

If you routinely make changes or a new features on a frequent basis to an app likely to be used on a regular basis, some people might find it unappealing that each time they use the app it changed. Today no one ever puts in release notes about what is different (probably since most people never read them) so finding out by random chance is more likely (hey where did that button go?).

You might say: there are bugs so we need to get fixes to our customers quicker. Are there serious bugs because you are shipping the apps too quickly to create quality? 30 years ago we didn’t ship until the app was solid since we couldn’t send out patches, today patches are so easy that people just assume they can fix whatever they break quickly. I suppose its acceptable to “break things and fix quickly” but I still prefer not to ship out broken crap in the first place.

Another thing people rarely consider is that frequent updating of apps can also cause a lot of bandwidth usage on your customer’s devices especially they have automatic downloads turned on. If your app is 150MB and you release every two weeks thats 7.8GB a year! Maybe that’s not a lot but in the upcoming nightmares in the ISP world with the loss of a neutral internet bandwidth might become precious again—or horribly expensive.

I noticed that TripAdvisor, who has a canned release note about shipping every two weeks, had a long break where they didn’t seem to update the app for a couple months. Naturally when they shipped again they kept the same message! The downside of a fast pipeline with a large staff is the inability to make major changes, either functional or architectural, without a massive branch dance that no one finds fun. It’s hard to do a big addition if you have to keep integrating other changes continually, causing more problems with automated and unit tests breaking left and right. Eventually speed kills and now you have a lot of problems getting it back.

I have never been a fan of shipping on a short schedule, I’d rather ship quality without the constant fear of breaking things and be able to spend at least some time thinking about how to do it right. I also am not a fan of huge teams where no one actually does very much in the interest of shipping fast.

I do wonder what your customers think if you ship every week or every two weeks versus every month or every two months. Do they even notice? Does it change how they use your app? If the only reason to ship fast is that you can brag you ship fast but your customers get nothing out of it and your cost of development is very high is it really a good idea?

At my job we ship every two months and the process is byzantine and horrific and more words I’d rather not type out. It’s the opposite of fast—we have too many people, a highly fragile code base, outsourced testing, and massive fear of shipping anything broken which of course happens anyway. I can’t change anything about it which is very frustrating. I am also sure we are not the only company in this mode of slow and expensive and messy.

There is happy medium, where releases happen at a rate which is easy to sustain yet can be speed up if needed. At the travel company two jobs ago we shipped reasonably fast (once a month or so) yet when needed to we could find a bug, fix it, test it and release the same day. The staff was small, localized, with minimal process and amazing testing resources. Despite having several apps (5 native mobile, a mobile web and a mobile api) we supported these with only 12 programmers total plus a few testers, a few designers and a scattering of managers. This type of small integrated team with little overhead allowed us ultimate flexibility to ship what made sense, either slow or fast as needed.

I’d rather have a team that was this flexible and a company that understood what its customer base really needed. I’d rather ship a quality app that didn’t require patches with a process that supported this flexible attitude. Too fast is not really a panacea and too rigid a process isn’t great either. Putting pressure on a team to deliver deliver deliver always at warp speed probably contributes to massive burnout. Sure companies like Facebook and Uber seem not to care about how many people they hire and what it all costs but that still seems crazy to me.

Even at my employer (non technology but every knows us) we waste enormous money on way too many people and a way too complex and horrible process that is also way too slow and inflexible. I know a lot of people here who want to have that quick every two week auto pipeline but that’s not going to happen either. To support rapid pace you have to have a good architecture, good discipline, a lot of people who do very little every day and be willing to avoid big changes. We don’t have any of that.

My experience at the Travel company (now sadly just a marketing brand of someone else) showed that there is a middle ground that is cheaper, more flexible and a whole lot more fun to work at. Yet even that requires a company willing to have fewer people but allow more freedom to innovate and hire good people who want to stick around and be part of this, and that isn’t going to happen at many companies. I was lucky to experience it.

Maybe a fast pipeline with a massive number of people works for you, I hope it’s worth the cost in dollars and in burnout. I sure know that massive people and a slow pipeline from hell isn’t working too well either! For me, I’d rather be in a small flexible team and ship whenever it’s a good time.