Hacker News Reader

Comment by zeroz | Hacker News Reader

Good summary. One missing argument IMHO against continuous deployment: Fear of consequences in strong regulated sectors, like finance and insurance. Continuous delivery is highly encouraged, but for deployments I see strong preferences to test everything (in some parts automation is still weak) and therefor some bundling of deployments or special dates are still preferred. I think costs of bad reputation or being watch by regulators because of failed or illegal 'transactions' are in these businesses much higher than e.g. in retail, gaming, etc.

View on HN

And meanwhile, we have Equifax losing tons of valuable data due to a breach caused largely by how slowly they deploy, and how difficult it is for them to get rid of antiquated technology.

After many years in big enterprise, I've learned something important - the appearance of risk is more important than the existence of risk. Continuous delivery looks "risky". Slow, deliberate release cycles on a quarterly or even yearly basis look "safe", because "testing".

In practice, those quarterly deployments have far too many changes embedded in them all at once. Worse, teams race to get their features in under the deadline, knowing it can be months before they'll get another chance, leading to careless coding and inadequate testing. So, based on both my experience and a little beyond-common-sense logic, slow release cycles are more risky than fast ones.

I absolutely agree with you! These huge quarterly updates with last minute hop on's and changes ("otherwise we have to wait another three months") which large enterprises did or are still doing are more risky than smaller ones. Does this require to jump directly to continuous deployment? I don't think so. What's wrong with continuous delivery to user acceptance stage and e.g. two weekly deployments after ~98% automated tests ~2% manuel test (especially penetration).

Agreed, and I think you could coin that as the Risk Corollary to Pournelle's Iron Law of Bureaucracy. Because a bureaucracy's control is eventually driven by political considerations rather than results, a bureaucracy's risk management policy will eventually be driven by politics rather than results, and as such, policy will attempt to reduce the appearance of risk rather than reduce risk itself.

The other failing of this sort of recommendation is that it assumes all software users are using software the same context: that being as individual consumers or maybe small groups. In that context, there's some good sense.

However, consider the enterprise context where I have thousands or even tens of thousands of people that have to use the software in some coordinated fashion. A new application feature may be useful under the right circumstances, but trying to be sure what the best and most appropriate uses of a new feature in a large organization often times just cannot be an ad hoc affair. Part of the job of enterprise business applications is to centralize information and make processing that information more efficient. When the usage of that system in the field is not consistent however, then you lose a lot of that benefit.

I'm sure the author wasn't thinking about the boring old enterprise, but without context in the article it's difficult to say whether the advice is meant to pertain to the consumer focused startup or all comers.

So put the new feature behind a toggle, let trusted power users play with it, and schedule the removal of the toggle for when it is appropriate.

Continuous deployment is something that you can only truly achieve when you have a very high degree of confidence in your automated testing IMHO.

Reply on news.ycombinator.com