Designing for Operations - The Practice of Cloud System Administration - page 43

Figure 2.1: Implementation priorities for design for operations
Fixing the biggest bottleneck usually has the biggest impact. This point will be dis-
cussed in greater detail in Section 12.4.3 .
Oneofthedifferenceswehavefoundbetweenhigh-performingteamsandlow-perform-
ing teams is that the high-performing teams focus on impact.
Case Study: An 80/20 Rule for Operational Features
When Tom was at Lumeta, a disagreement arose over how much developer time
should be spent on operational issues versus new features. The product manager
came up with a very creative solution. The product alternated big releases and
small releases. Big releases were expected to have major new features. Small re-
leases were expected to fix bugs from the previous major release.
It was negotiated that big releases would have 20 percent of developer time
spent on issues requested by the operations team. The small releases were not in-
tendedtoaddmajornewfeatures,butitwasusefultohaveoneortwohigh-priority
features included. Therefore, for small releases, 80 percent of developer time was
spent on operational requests. Since the releases were smaller, the same number of
hours was spent on operational requests for both big and small releases.
2.2.3 Write the Features Yourself
When developers are unwilling to add operational features, one option is to write the fea-
tures yourself. This is a bad option for two reasons.