Special Thanks: This article was made possible by support from  Linux Professional Institute

The world of software development is built on a foundation of two awkward metaphors. First, there’s building construction, in which software has “architects” that help with the “blueprint” of the code and then turn it over to the software developers who “build” it. The second metaphor is complex manufacturing, wherein software development has highly specialized phases that work in a conceptual pipeline [1]. Designers design and then hand it off to developers who develop, who then hand it off to testers who test.

It turns out, though, that these are pretty poor metaphors for creating software. Understandably, early software developers would rely on parallels to known professions, but in reality, that doesn’t work very well.

Software development doesn’t operate like the construction industry. Buildings require tons of upfront planning, because not much can really be changed once you’ve laid the foundation. However, that’s not true at all for software. Also, software development is knowledge work [2] and doesn’t look like manufacturing, because you can’t break it down into simple, repetitive tasks to be executed by low-skill assembly line workers.

Some of the most important sea changes in software have taken aim at these metaphors: take the agile software development movement [3], for instance. It took aim at excessive formalism, process, and heavy upfront planning, all characteristics of the construction industry and complex assembly lines. Instead of putting more and more effort into planning and locking plans into place, why not concede the inevitability of change and get good at responding to it? The agile software movement, at its core, spoke to the uniqueness of software and the unsuitability of other metaphors.

The Rise of DevOps

Agile got rid of the phased, specialized hand-offs between business representatives, developers, and testers. Why make these folks do their jobs in a vacuum? Successful software development requires collaboration among all of these people throughout the development process. Instead, they collaborate and ship early and often to respond to feedback and changing requirements.

Once the software is pushed to production, the development team doesn’t have to worry about it anymore; then, it’s Ops’ problem.

I plant my tongue a bit in cheek as I say this. I don’t think proponents of agile would actually  have said this during the 2000s, but it does underscore how the early days of agile brought all parties to software development to the table – except for operations. It would take some years and a different, but related, movement to do this.

That new movement was called DevOps, and it finally brought the operations folks to the party. DevOps, like agile before it, has become something of a buzzword, but at its core, it’s about the recognition that a formal, phased hand-off between development and operations makes as little sense as treating software like a construction or manufacturing project.

The result? Software development efforts have started to include operations experts early and often in the process, and developers have increasingly automated aspects of operations, including deployment, configuration, and monitoring.

This process is called DevOps. It’s new, broad in scope, and often confusing. This means that DevOps adoption comes with a minefield of potential mistakes. I’ll look at some common mistakes and how to avoid them.

Eschew DevOps Departments

I led with the background of software development, because it’s important to understand where it”s been and where it’s going. Decades and untold billions of dollars have been wasted trying to segment and specialize software development, rather than assembling cross-functional teams [4]. Agile and DevOps both avoid those past mistakes.

This makes the first mistake I talk about particularly ironic, if understandable. Say some enterprise program or IT department wants to get on board with the DevOps movement. What do they do? They create a DevOps department.

Most likely, this new department includes a half-and-half mixture of former software developers and former IT operations and support folks. "Go forth, mingle your knowledge, and sit between development and operations," management instructs. They probably sprinkle in some self-directed training and workshops while they’re at it.

This fundamentally misses the point. If you want to avoid this path, consider what I described with agile. High-functioning agile teams brought business analysts and testers into the development fold, treating them as first-class members of the team. You achieve DevOps by doing the same thing with IT operations and support: Make them part of the teams they support – don’t create a third department on top of the two disjointed ones you already have.