This is easiest to see in deployment. When something goes wrong with production software, it's almost always because of an unintended side effect of some piece of code. Think about the last time you were called upon to debug a problem like that. How much of the time you spent debugging was actually dedicated to fixing the problem, compared to the time it took to track down where the bug originated?
When bugs are found quickly, they can be fixed quickly. Take the example of Flickr, which practiced continuous deployment before being acquired by Yahoo!. As John Allspaw states:
Amongst many Yahoo! properties, including the largest ones, which have quite dialed-in ops teams, Flickr's MTTD was insanely low because of this. Since only a handful of lines are changed when they are deployed, changes that do cause regressions or unexpected performance issues are quickly identified and fixed. And of course, the MTTR (Mean Time To Resolve) is much lower as well, because the number of changes needed to fix or roll back is not only finite, but also small.
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.
