Ever Ready

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.

Change the Development Culture

Once you've avoided the pitfall of the "DevOps department," you face a new foundational challenge. The folks with operational expertise are ready to mingle with the team, automating deployments, configuration, and monitoring, but is your development culture ready for that mingling?

One of the biggest mistakes from the early days of agile revolved around not changing the technical practices. Software groups used to shipping software on a yearly basis were in for a serious culture shock. Agile methodologies generally demand that you ship once every few weeks. This resulted in a lot of awkward, halting, and failed adoptions of agile, in which the team just wound up having slightly different meetings.

You face the same conceptual issue with DevOps. Collectively, as an industry, teams have automated elaborate deployment pipelines, allowed scripted, on-demand configuration of environments, and gotten monitoring technologies down to a science; however, to leverage all of that, they need code that exists in a perpetually deployable state, a mistake that many shops have not realized.

If you're used to having days or weeks between deployable versions of your code, all of the DevOps in the world won't help you. It would be like pulling up to a nice, smooth road with a car that has no gas. Before adopting DevOps, make sure you've matured your development culture.

Avoid Long-Lived Feature Branching

In some ways, this mistake is a more specific version of the previous topic, but it's worth calling out separately because that's not always the case.

In the broadest terms, you have two collaborative workflows at the end of a spectrum: trunk-based and feature-branch-based development. Trunk-based development means that developers work at all times in a mostly coherent, single version of the codebase. Feature-branch-based development means that the team works in a way that gives individual features their own, isolated sandboxes.

Going into the pros and cons of each approach is beyond the scope of this article, but I will speak to what they mean for your DevOps adoption efforts. Source control tools have an outsized effect [5] on which approach you adopt, just as your approach has significant ramifications for DevOps as a methodology.

If you favor feature-branch-based development, you're going to suffer a lot of pain with DevOps adoption. DevOps automates many aspects of how you treat your code between developers' machines and production environments. Keeping many different conceptual flavors of your codebase around makes DevOps concerns an order of magnitude more complex.

Make your life easier by migrating toward a trunk-based workflow.

Adopt Granular Codebase Instrumentation

To conclude, I'll talk about something you'll probably only face once you've done well with the previous three tasks, because this mistake occurs once you have successfully adopted the practices and are moving code around between your environments with ease.

With this issue, you fail to realize all that you can get out of your new capabilities. You move your builds around with ease, but you move them around as monoliths. This is a mistake, because you lose track and control of new features.

With trunk-based development, you stop managing features through version control and start managing them through selective deployments [6], which you achieve the way companies like Facebook do: with a feature flag management system [7]. Doing this lets you configure not only operational data but also entire sets of features and the user experience.

To achieve the most flexibility with production concerns, you need to alter your codebase. Make sure it's flexible, conceived in granular fashion, and easily partitioned, because DevOps isn't just about automating how you deploy things – it's about automating how you handle them once they're deployed.

Conclusion

The software industry started by basing itself on flawed metaphors and then corrected course with movements like agile development and DevOps. Although these terms have been overplayed into buzzword status, beneath the surface, they offer real wisdom and insight. If you can see past the hype and avoid key mistakes, you'll get an awful lot of value from these corrective movements in the industry.