An example of this is integration risk, which we use continuous integration (http://startuplessonslearned.com/2008/12/continuous-integration-step-by-step.html) to mitigate. Integration problems happen when two people make incompatible changes to some part of the system. These come in all shapes and sizes. You can have code that depends on a certain configuration that's deployed on production. If that configuration changes before the code is deployed, the person who changes it won't know he's introduced a problem. That code is now a ticking time bomb, waiting to cause trouble when it's deployed.
When the explosion comes, it's usually operations that bears the brunt. After all, it would never have happened without that change in configuration (never mind that it also wouldn't have happened without that new code being written, either). New code is generally perceived as valuable forward progress. Configuration changes are a necessary overhead. Reducing the odds of them colliding makes everyone's life better. This is counterintuitive. It seems like having more releases will lead to increased odds of things going wrong. As we'll see, that's not actually correct. Slowing down the release process doesn't actually reduce the total number of changes—it just combines them into ever-larger batches.
Get Web Operations now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
