Automation is necessary once we have abundance. When we were still working at a scale where a person could FTP files to a server to update a web page, we didn’t need it. It was only after we reached a point where The Web and The Internet and Online are all one enormous space did we need to learn to automate page updates to maintain our sanity. 

When we talk about automation as a part of Progressive Delivery, remember that we can’t automate what we don’t understand. We need to know what we want included, at least by class, and what we want for outcomes. We need to understand enough of what we’re building to be sure that our automation is what it needs to be.

Move from explore to bore

When something moves from “nifty” to boring, when it becomes maintenance instead of invention — that’s the time that automation is useful. We’ve charted paths, now they need to be widened and paved. Once it’s known, it can be automated, it can be boring, it can be table-stakes. But to get to that place, we need to blaze the trail and understand the destination.

Automation can’t stand alone

Automation depends on us to define where we want it to go or stay away from. When scientists were experimenting with slime molds to draw efficient transit networks, they put food at major city nodes and made bodies of water off-limits. The slime mold fit itself to those constraints, and we ended up with a perfectly usable transit map.

If we say that content moderation should ban or hide certain words, we don’t get a reduction in those sentiments, we get a bunch of people and machines working around the ban and saying things like “unalive”. That’s because automation is doing exactly what we told it to do — ban a specific word. That’s a constraint, but the automation doesn’t, can’t understand the goal.

Automation needs other parts of our As, like Abundance, Autonomy, and Alignment to work well. We can’t make rules for execution if we don’t have the resources to enforce/encourage them. We can’t be consistent if we don’t have a way to let the system and its parts act and react. Our rules are far less useful if they’re not aligned on the goals and outcomes of the system. When we construct automation, we’re building on all the parts of the system that we’ve already discussed. 

Progressive delivery is iterative, not linear. 

Once you automate something, you may find a way your system can have more autonomy, so you rework it. Your software is never finished.

Automations save time and effort. Or do they? 

The perpetual promise and dream of automation is that it will save us time and effort. However, Jevon’s Paradox says that as we make something more efficient or cheaper, use increases. You can probably think of examples in your own life, like the difference between paying per text and having flat-rate texting.

One of the reasons we continue to believe that automation will reduce work is because many of our automations hide or abstract complexity and work away from us. But abstracting complexity is not the same as eliminating it. We are just shuffling it around so we don’t have to look at it.

Julia Evans wrote a post about what happens when you press a key in terminal. Hundreds of words later, we have learned about escape sequences, terminal encoding, echoing, and newlines. And that’s not even how the information is processed, just how it’s sent to the server. We don’t have to think about that, though. Which is good, since we’re also remembering commands to get what we want, and carrying a mental map of the system that we’re working in. If I type ‘ls’, I expect to get a list of the files in the folder that I’m in. That means that I have expectations about “files”, “folder”, and the whole file system.

Automation saves us from having to consciously think of each of those things, but it’s still a complexity that exists, even when we’re not making eye contact with it.

On the other hand, automation can save us a lot of effort if we use it wisely. Think about any painting software you’ve used. You can tell it to draw a circle, and adjust the size with your mouse. Then you can use the fill tool to make everything inside the circle a new color. Drawing circles is hard for humans! We’re bad at it. Now imagine coloring in your circle exactly evenly with no visible pencil strokes and the color is all exactly flat and the same. It’s not a thing we can do! But we do it all the time with software. We have automated something that is hard and tedious, by tricking rocks dreaming in numbers for us.

The best automation is not just a reproduction of human effort, only harder and faster. Instead it is like the water, or the slime mold, a better solution that is not how humans work.

Automation in Progressive Delivery

Progressive Delivery tends to assume that you’re doing continuous integration and continuous delivery/deployment. We have automated all the mechanical parts of being a release manager, leaving only the residual and not-at-all difficult emotional labor parts. 

We have automated lots of the predictable testing, unit-level and integration testing, leaving only the exciting parts where everything works fine except this one weird edge case. We have automated bug tracking and payments and workflows and authorization and authentication. What we have left are mostly the interesting problems. And we all like working on interesting problems more than rote, automatable problems.

Of course, nothing stays automated, any more than software is ever finished. It’s a part of the process of Progressive Delivery that needs to be revisited regularly. And that is its own kind of interesting.