The world of software development built itself on a foundation comprised of two awkward metaphors. First, there’s building construction. 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. Software development has highly specialized phases that work in a conceptual pipeline. Designers design, then hand it off to developers who develop, who then hand it off to testers to test.
It turns out, though, that these are pretty poor metaphors for creating software. It’s understandable that early software developers would rely on parallels to known professions. But still. It doesn’t work very well.
Software development doesn’t look like building construction. Buildings require tons of up-front planning because you really can’t change things once you’ve laid the foundation. But that’s not true at all for software. And software development doesn’t look like manufacturing. It’s knowledge work, so 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 movement, for instance. It took aim at excessive formalism, process, and heavy up-front planning, all characteristics of building construction and complex assembly lines. Instead of putting more and more effort into planning and locking plans into place, why don’t we 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 have these folks do their jobs in a vacuum? Successful software development requires collaboration among all of these people throughout development of the software. We’ll have them collaborate and then ship early and often so we can respond to feedback and changing requirements.
But once we actually push the software to production, then none of us will worry about it. 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 is called DevOps, and it finally brings the operations folks to the party. DevOps, like agile before it, has become something of a buzzword. But really, 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.
We call all of this DevOps. It’s new, broad in scope, and often confusing. This means that DevOps adoption comes with a minefield of potential mistakes. Let’s look at some common ones and how to avoid them.
Avoid Creating a “DevOps Department”
I led in with the background that I did because it’s important to understand where we’ve been and where we’re going. We’ve wasted decades and untold billions of dollars trying to segment and specialize software development, rather than having cross functional teams. Agile and DevOps both steer us away from those past mistakes.
This makes the first mistake here particularly ironic, if understandable. Let’s say some enterprise program or IT department wants to get on board with the DevOps movement. So, 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 fundamentally missing the point, 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.
You Need to 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, we’ve automated elaborate deployment pipelines, allowed scripted, on-demand configuration of environments, and gotten monitoring technologies down to a science. But to leverage all of that, you need code that exists in a perpetually deployable state.
The mistake that many shops make is not realizing this. If you’re used to days or weeks between having deployable versions of your code, all of the DevOps in the world won’t help you. It’ll be like pulling up to a nice, smooth new road with a car that has no gas in it. Before adopting DevOps, make sure you’ve matured your development culture.
Stay Away from Long-Lived Feature Branching
In some ways, this mistake is a more specific version of the latter. 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 development and feature-branch-based development. Trunk-based development means that developers work at all times in a mostly coherent, single version of your 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 post, but I will speak to what they mean for your DevOps adoption efforts. Source control tools have an outsized impact 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.
Instrument Your Codebase in Granular Fashion
I’ll conclude with something you’ll probably only face once you’ve done well with the previous three. That’s because this mistake occurs once you’ve had a successful adoption of 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 miss out.
With trunk-based development, you stop managing features through version control and start managing them through selective deployments. And you achieve this the way companies like Facebook do: with a feature flag management system. 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 that 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.
The software industry started by basing itself on flawed metaphors. It then course corrected with movements like agile and DevOps. Sure these terms get overplayed into buzzword status. But, beneath the surface, they offer real wisdom and insight. If you can see past the hype and then avoid key mistakes, you’ll get an awful lot of value from these corrective movements in the industry.
