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

First, the developers might not accept your code. As an outsider, you do not know their
coding standards, the internal infrastructure, andtheir overall vision forthe future software
architecture. Any bugs in your code will receive magnified blame.
Second, it sets a bad precedent. It sends a message that developers do not need to care
about operational features because if they delay long enough you'll write them yourself.
Operational staff should spend time coding operational services that create the ecosys-
tem in which services run. Write frameworks that developers can use to improve opera-
tions. For example, write a library that can be linked to that makes it easy to report status
to the monitoring system. Write tools that let developers be self-sufficient rather than de-
pendent on operations. For example, write a tool that gathers exceptions and core dumps
for analysis rather than emailing requests to operations anytime that step is needed.
There are exceptions to this rule. Code submissions from outsiders are easier to accept
when they are small. In a highly collaborative organization, people may simply be more
accustomed to receiving code contributions from many sources. This is typical on open
source projects. At Google there is a code approval process that makes it easy for outsiders
to contribute to a project and assure the code meets team standards. This system permits
feedback and revisions until the code change is deemed acceptable by both parties; only
then is the code accepted into the system. It also helps that there is a corporate-wide high
standard for code quality and style. In such a system, the code quality and style you are
used to writing will probably be compatible with that of other teams.
When possible, operational staff should be embedded with developers so they can learn
thecodebase,becomefamiliarwiththereleaseandtestingprocess,andbuildarelationship
with the code. However, even that is no replacement for getting operational features added
by the developers themselves. Therefore it is better to embed developers with the opera-
tions staff,possibly insix-month rotations, sothat they understand the operational need for
such features.
Whatworksbestmaybedictatedbythesizeoftheorganizationandthescaleofthesys-
tem being operated. For example, a high degree of collaboration may be easier to achieve
in small organizations.
2.2.4 Work with a Third-Party Vendor
Working with a third-party vendor is quite similar to working with your own development
team.Manyofthesameprocessesneedtobefollowed,suchasfilingbugsandhavingperi-
odic meetings to discuss feature requests.
Always raise the visibility of your issues in a constructive way, as vendors are sensitive
tocriticism oftheirproducts.Forexample, writeapostmortem reportthatincludesthefea-