releasing

Software update cycle: faster every day

Posted on by will

My Atari 2600 never got a firmware update. Not a single one. Neither did any of the game cartridges that came with it.

In the early days of software, ‘soft’ware was really just a different kind of hardware. It was built, packaged and shipped exactly once. If you shipped it with a bug, that bug would stay there.

‘Softer’ storage types (tapes, floppy disks, etc) and better distribution allowed software companies to release new versions more often. Many years between major versions became one or two years, but updates to a specific version were uncommon.

The internet shortened the cycle even further – turning one or two years to months for many software products, and allowing automatic updates of existing versions to fix bugs, patch security holes, and so on.

Seamless and fully-integrated update and application management technology, like the App Store for Mac, can bring the cycle down even futher – changing months to weeks between updates.

What happens when the cycle is even shorter? Then you get web products. Sites like WordPress.com or Amazon can push an updates to production servers multiple times per day.

How fast are you?

Continuous delivery: release early, release often

Posted on by will

If you’re in the business of building a car, you only really only have one chance to get it right. Those years of research and development, trials, testing, marketing and building culminate in a single, big release – your car launch. You only have one chance because by the time your customers drive your car away from the lot, it’s too late to fix that overheating problem with the brakes, or add another 0.5L engine capacity. Shame.

Software used to be the same way. A software project would be analysed, specified, analysed again, specified again, built and re-built and finally, after months or years of development, would be burned onto a CD or floppy disks, put in a box and sent to a store. Before the internet getting updates to software was tricky. You had just one shot to get it right.

Today, we live in a very different software world – especially true for those of us working on web products. With the internet we have a delivery immediacy unlike any other product manufacturing system in the world. We can make a change today and our customers see it in their product, today. You can add a new feature today and start generating new revenue or new customer acquisitions tomorrow.

It goes further. You can release a feature today, and watch, in real time, how your users interact with it. If your key metrics go down, you can roll the feature back out. If there’s a problem, you can either fix it quickly, or roll it back. You have the power to interact directly with your customers immediately over the best channel possible: the product itself.

This is what continuous delivery is all about. It’s like a beautiful gift for any product developer, and I think not making the most of it is a waste of that gift. Release early, release often.

Maximise success

Posted on by will

Many processes and organisational controls are set up to minimise failure. They are set up to minimise the number of times a team releases bad software; minimise the number of customer complaints; minimise the server crashes or minimise the failed product launches.

What if instead of trying to minimise failure, your organisation focused on maximising success?

What would it do for your product or consumer offering if instead of trying to minimise the bad software releases, you focused on maximising good ones? What would it do for your organisation if instead of focusing on minimising failed product launches, you focused on maximising good ones?

The problem with focusing on minimising the bad is that it creates roadblocks instead of opportunities. When a conversation starts with the question “do we have a reason to not ship this?” it sets the expectation that not shipping is okay. A focus on bad minimisation discourages risk taking and rewards the status quo.

The easiest way to minimise bad releases is to not release anything at all – so when you incentivise and reward the act of not shipping bad releases, either nothing will get shipped, or what does get shipped will be safe and unremarkable.

There will always be a reason not to ship if you look hard enough. Instead of focusing on trying to find it, try investing that energy into shipping it the best way you know how.