Continuous Development alone does not solve the pain of change

Continuous Development? Harvard Business Review thinks it is pretty awesome and describes it as this:

“Rather than improving software in one large batch, updates are made continuously, piece-by-piece, enabling software code to be delivered to customers as soon as it is completed and tested.” - Harvard Business Review

But, what are your customers going to do with it? 

For the customer, downtime is a greater enemy than the change itself. 

Do big releases scare you? Then so should little ones. You aren’t going to suddenly be better at change and release management just because you made the payload smaller.

Therefore, continuous development starts with a return to the dry erase board. Disruption seems to always require a redesign. 

Before the cloud, every infrastructure component had to be robust enough to meet availability requirements. The cloud forced us to build availability into the product because we gave up control over the infrastructure.

I believe that you must also rethink your application design. Instead of baking-in availability, the focus for micro-releases has to be reducing their impact on the customer. Perhaps even, dare I write, code releases that require no downtime. 

If micro-releases cannot be done without downtime, then the customer will continue to only be drawn to a release if it includes new functionality or fixes a bug. That’s the only time they will be impressed by “speed to release”. 

Just like determining which workloads are a good fit for a move to the cloud, an organization will have to determine which applications are a good fit for continuous development. You must improve the deployment experience first.