municated to a supplier. Initially the
system talked to only one supplier, so
that was pretty easy. Then a second
was grafted on. Then another. Some
features had to be implemented three
times, once for each supplier. This was
When asked to support a fourth supplier, the developers revolted. Yes, they
could graft it on in about a month, but
the software was starting to creak like
an old house in a hurricane. The quick
fixes had accumulated technical debt.
Their proposal was to spend two
months refactoring (reworking) the
supplier architecture so that it was a
plug-in system. New suppliers could
then be added in a week, not a month.
The executives were not happy. Why
would this next supplier take more
than two months to add when previous
suppliers were added in one month?
The two months invested in paying
down technical debt would make future additions faster, stabilize the code
base, and make it easier to add new features. It is difficult to measure the exact
You can pay me now, or pay me later.
It is your job to allocate time to pay
down technical debt. Runaway technical debt slows down the ability to add
other features, and it leads to unstable
software. Paying down technical debt
should be tied to business goals, similar to nonfunctional features.
9. Software doesn’t run itself.
While vendors and developers may try
to tell you otherwise, software doesn’t
just run itself. Any software-based system (websites and Web applications,
in particular) requires operational
staff and processes; otherwise, it just
sits there like a closed book. Someone
has to turn it on, care for it, and tend
to its needs.
I assert that operations is more important than software development itself. Code is written once but runs millions of times. Therefore, operations
are, by that rough measure, millions of
times more important.
As a result, it is your job to expect
operations to be part of any software-based system. It must be planned for,
budgeted, managed, and run efficiently just like anything else.
Operational features (usually called
nonfunctional features) are invisible to
users except as second-order effects.
Data backup is a good example of a
nonfunctional feature. No user requests data to be backed up. Users do,
however, ask for deleted data to be restored. Sadly, there can be no restore
without a backup. A restore is a functional feature; a backup is an operational (nonfunctional) feature.
Features that make a software service easy or efficient to operate are never requested by users. They do, however, enjoy the benefits of a system that is
cost effective and reliable. Customers
leave unreliable websites and don’t
Software must be scaled, monitored, updated, and so on. Wikipedia
has an excellent list of nonfunctional
requirements that drive such features. 13 Operations are in a constant
battle to improve efficiency. This often
requires new code.
The need for continuous improvement includes not just new features,
but new nonfunctional features. Therefore, it is your job to allocate resources
not only for the features that customers demand, but also for operational
features. Striking a balance between
the two competing needs is difficult.
A successful product is the negotiated union of business and operational
10. Complex systems need
DevOps to run well.
A complex system is best improved
through DevOps. This has many definitions, but I prefer to think of DevOps
as accelerating the delivery of value
(features, bug fixes, process improvements, and so on) by rapid iteration.
To achieve this, everyone involved
must participate. That is, they must
work across silos. The name DevOps
comes from the movement to remove
the wall between developers and
operations (IT), which is absolutely
required to achieve rapid releases.
Great DevOps environments, however, extend this to work across all silos
end to end.
DevOps has been misinterpreted to
mean developers perform operations.
This “you build it, you run it” strategy is
one way of working across silos (
eliminating them), but it isn’t the only way.
More on that later.
The system that builds and continuously improves your software is
a machine. Every time you turn the
crank, a new (hopefully improved)
release of software pops out and goes
Delivering your product to customers is also a machine. Your marketing,
sales, logistics, billing, and other systems all work together. Every time you
turn the crank your product is delivered.
Either kind of machine is a complex
system with many dependencies. To
run well, a complex system needs three
things: a good process, good communication by all the people involved, and
the ability to try new things.
These are codified as the Three
Ways of DevOps:
˲ The first way is “system thinking” or “flow.” The focus here is on
improving the end-to-end process,
not specific silos, as described in
item 7. The First Way is about driving
improvements that move you from a