Building better software on schedule with DevOps

Collaboration Station

A Question of Culture

In addition to the more tangible aspects of the new IT methodology, which have much to do with technology and tools, don't forget the human factors that influence the work in IT. This includes job satisfaction, for example, which DevOps can help improve, thanks to productivity increases. Before that can happen, however, a few requirements need to be fulfilled.

The non-technical conditions for DevOps [8] can be described as organizational culture. This includes not seeking scapegoats in case of errors and problems (Figure 2). If the developers put the blame on the Linux admins, who in turn point to network people, this approach is of little benefit to the users. Gene Kim describes this vividly in his instructive story The Phoenix Project (see the "DevOps Novel" box).

Figure 2: Blaming breakdowns on others is frowned upon in DevOps. Instead, the idea is to learn from mistakes (© alphaspirit, 123RF).

DevOps Novel

The Phoenix Project [10] is a work of fiction, which at the same time teaches DevOps principles. It was written by entrepreneur Gene Kim along with several co-authors. As a student, Kim programmed the intrusion detection tool Tripwire and later founded the company of the same name. Since 2000, he has focused on IT organization, written books, and presented keynotes.

The novel tells the story of Bill Palmer, who surprisingly is promoted to head of company-wide IT operations, although he was only the head of a small department at the time. In his new role, Bill has many difficulties to cope with: On his first day, payroll accounting goes haywire, and the company makes negative headlines in the press. Additionally, the new software release – code-named "Phoenix" – is already two years behind schedule. As if all of this were not enough, the Sarbanes-Oxley auditor is waiting in the wings with a long list of complaints.

Time is short and Bill does what he can. He first discovers what is wrong with the system: The right hand has no idea what the left hand is doing; Most system knowledge is concentrated in a single employee, and no one adheres to processes or writes documentation.

The problems described, the characters, and the dialog are so true-to-life that anybody who was worked in IT will empathize with the sufferings of the protagonist. The company needs some sort of change management tool so that the changes do not get in other people's way. Wes, an employee from Bill's department, protests: "It takes twenty minutes to fill out the whole damn fields, even if it's just a simple five-minute task!"

If you follow Bill's progress, you can learn much about the problems of an organization  – and how to solve them. Especially when the mysterious Dr. Reid appears, who becomes a kind of mentor for Bill.

Gene Kim, Kevin Behr, George Spafford:

The Phoenix Project

IT Revolution Press, 2013

350 pages

US$ 17 paperback

US$ 9.99 Kindle

UK£ 13.42 paperback

UK£ 6.37 Kindle

Errors Are Natural

In their lecture in 2009, Allspaw and Hammond called for a healthy attitude toward failure: Mistakes would always happen, they said, but you can fix them and learn from them – for example, by keeping the remedy in a knowledge base or setting up a contingency plan. Netflix takes this principle to extremes. It uses a tool called Chaos Monkey [9], which switches off randomly selected services to test the resilience of the cloud and train the work processes for troubleshooting.

The values of DevOps culture also include respect: Prejudices against developers as being lazy and reckless or stereotypes of admins as bureaucratic naysayers have no place here. Everyone works toward a common goal and shares opinions and knowledge. It is unacceptable, for example, to withhold information from others, cover up your own mistakes, or strengthen your own position. Such power games cost time and energy and impair the company's success. Instead, DevOps relies on trust between all parties, including, for example, admins allowing programmers to make certain changes to systems.

Exemplary

Of course, employee attitudes cannot be planned at a board meeting. This is an emergence process that typically requires slow changes. Consultant Mandi Walls [8] recommends, among other things, that senior employees and respected professionals act as role models. Additionally, a well-defined pilot project is best suited, in her opinion, for testing and introducing the new approach.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Common DevOps Mistakes
    From industry metaphors, to agile processes, to DevOps, software development is evolving into a mature enterprise. We point out some missteps in the adoption of the DevOps methodology.
  • A REST API automation strategy for DevOps
    Making resources available through REST APIs breaks down the automation silos that cater to the different IT and development environments and sets up an application-centric automation approach.
  • Container technology and work organization
    DevOps and container technology often appear together. If you have one of them, you get the other automatically. However, as the following plea for reason shows, it isn't always that simple.
  • Jira, Confluence, and GitLab
    Jira, Confluence, and GitLab are very popular DevOps tools and often form the basis for agile work flows. With the right Ansible playbooks, Ubuntu can be turned into an agile work center.
  • Opportunities and risks: Containers for DevOps
    Containers are an essential ingredient for various DevOps concepts, but used incorrectly, they do more harm than good.
comments powered by Disqus