Service Delivery: The Build Phase - The Practice of Cloud System Administration - page 198

result of the platform's ability to provide better testing and other processes that are auto-
mated to assure consistency. An excellent discussion of this can be heard in Episode 33 of
the DevOps Cafe Podcast ( Willis, Edwards & Humble 2012 ) .
More specifically, a good service delivery platform should result in the following out-
comes:
• Confidence: We want a process that assures a high likelihood that each deploy-
ment into production will be successful. Success means application bugs are found
and resolved early, ensuring a trouble-free deployment without out-ages. The more
confident we are in our service delivery process, the more aggressively we can try
new things. Innovation requires the ability to aggressively and fearlessly experi-
ment. Consider the opposite case: a company full of people who resist change does
not innovate. As fear of change increases, innovation declines. If we can confid-
ently try new things, then we can experiment and innovate, knowing that we can
count on our service delivery system to support our innovations.
• Reduced Risk: Faster iterations are less risky. As discussed in Section 8.2.4 , more
frequent releases mean that each release will contain a smaller number of changes
and, therefore, is less risky.
• Shorter Interval from Keyboard to Production: We want the end-to-end process
to happen quickly. We want to have our capital—the code developers create—in
the hands of the customers as quickly as possible. Compare yearly releases to
weekly releases. With the former, new features sit idle for months before they see
the light of day. That would be like an automotive factory making cars all year but
selling them only in December. Faster iterations mean features get into production
faster. This is important because the investment required to create a new feature is
huge.
• Less Wait Time: Faster iterations also mean code gets to the testing process soon-
er. This improves productivity because it is easier to debug code that was written
recently. Developers lose context over time; regaining lost context takes time and
is error prone. Less work has to be redone because testing helps get things right the
first time.
• Less Rework: We want to reduce the amount of effort spent redoing work that was
done previously. It is more efficient to get things right the first time.
• Improved Execution: Doing faster iterations improves our ability to execute all
the phases. When there is a lot of time between each iteration, any manual steps
become less practiced and we don't do them as well. If releases are extremely in-
frequent, the processes will have changed enough that it gives us an excuse not to
automate. We throw up our hands and revert to old, manual methods. Frequent re-