That’s not a huge problem; I deleted some photos and some apps, and then clicked to install an operating system update. Applying the update should apply the patch and also delete any obsolete code, right?
My phone never returned from the update. Instead, it came back with an image indicating the phone needed to be plugged into iTunes. I was away from my laptop for July vacation, so I was entirely out of service for two days. After that, when I plugged the phone in, I was told that the Mac needed to restore the phone from backup.
Sadly, I’m afraid we can expect more of this. Today, I’d like to talk about how to prevent it at our companies.
In my previous piece I claimed that companies were shipping more and more often, giving less time to testing and that while this might work just fine for certain web-based apps it might not for physical devices. Frequent software releases mean more frequent installs; that takes customer time and attention — customers in the habit of upgrading when it is convenient ad otherwise clicking “remind me later” will feel more pain. On the software side, it creates a testing crunch (or, possibly, quality problems). Automobiles, for example, have a model year release cycle; desktop software should probably be somewhere between annual and fifty times per day.
Someone is apt to point out that CD can be done better or worse, and that bad CD will be bad. I don’t think that’s quite the case here; it’s more like continuous delivery envy. Companies see Twitter, IMVU, and Etsy shipping all the time and think “that should be us!” without considering if the context is different.
One of my readers, Alan Parkinson, pointed out a key difference between Continuous Delivery and Continuous Deployment – that under continuous delivery, the business is in charge of when deploys happen. Whether the choice is “Batch up this set of features and release it”, or “release what you have every two weeks”, either way, a Product Owner (“PO”) is making a business decision. With Continuous Deployment, it is a member of the technical staff that pushes the deploy button, monitors production for obvious problems, explores the feature in production, and moves on to the next thing. There is no PO involved, and, indeed, the rest of the technical team might not even be involved.
In one example, the business creates a ‘bag of work’ that should be deployed together; in the other, the developer pushes the change. What I see happening next is an educated discussion of what changes can be pushed (text changes to static html), what needs a traditional test cycle (private information, credit card transactions), what code is in the middle, and what to do about that code in the middle.
There are a few known patterns to deal with the code in the middle. Here are a few:
* Have a component architecture, test the components that were changed, and watch a ‘lite’ end to end automated test run.
* Timeboxed exploratory testing, where we give the release twenty-four person hours and release if we find no show stoppers – that’s only three people for a day!
* Release to beta users, only executing the new code for risk-taking users who we email and ask to help us test.
If we can do it right, the next few years are going to be exciting.
And The Bonus!
I stepped back a bit this spring and winter from writing (a new baby in the house will do that). Instead of slowing down publishing, we recruited Justin Rohrman to join the writing staff, keeping our total at four articles per month. We continued our focus on people, process, and new technology, with Justin offering a fresh perspective.
It’s July. The baby is six months old. It’s time for me to get back in the game.
The problem is Justin is doing exceptionally well. His posts are consistently rated toward the top of ITKE’s blogs. We can’t lose him.
So we won’t.
Instead, Uncharted Waters is going to double in coverage, from four articles a month to eight. You don’t need to wait for a link from twitter or google plus to check out the blog; just wait a few days and click refresh on the home url for the blog.
As for us, we’ll need to continue to give you a reason to keep coming back. So let us know what you’d like to hear, what tweaks you’d like in our coverage.
In the meantime, if you’ll excuse me, I’ve got to go find our next story…