Like a mortician embalming the body of a healthy person who proclaims, "I've never felt more alive!" as formaldehyde floods their arteries, DevOps has been put to an early death by the commentariat on Twitter. But you can't kill the human desire to cooperate and DevOps is, above any technical solution, an inevitable result of scaling human activity in a software corporation.
DevOps, as a culture, as tools and practices, is living. If we want to continue turning the flywheel of its life, it's our responsibility to stoke the animating flame of its heart by extending it, not extinguishing it. DevOps has saved us from cross-team warfare but what about the runaway complexity in our development stacks?
The modern developer pushes their app to CI/CD pipelines that are so complex, their graphs resemble maps to fantasy realms and can take half an hour or more to run. They are incomplete and atomistic because each stage by which our code flows is context naïve. Think of the way a typical GitHub Actions pipeline acts on a commit: it may be responsible for everything from packaging code, to testing, to deployment, each step done by a discrete Action, published to the Marketplace by a different author, only acting on immediate inputs. When a pipeline fails, it fails no where near us, where we're playing jazz with the code at our fingertips.
And it's not only our pipelines which have become victims of this "complexity engineering": we continue to bake complexity in to our development toolchains. It's a silent creep of this tool or that tool until they number in the dozens and need a voluminous handbook to run or a platform team to vend.
In complexity we've forgotten the most important tool of all, human attention.
A transhumanist and a DevOps Engineer walk into a bar
I once styled myself a practicing transhumanist because I implanted a series of small magnets in my fingers with nothing more than a scalpel, some local anesthetic procured with the help of a patron, and sutures. Youthful and reckless proclivities aside, it was born from a deep desire to disappear into the computer I spent so much of my life growing up with, to thin the veil between the silicon chips on the motherboard and the sense of I.
What does this have to do with DevOps? An outcome of adopting DevOps in the workplace has been to increase developer velocity through automation and continuous delivery. Faster, tighter development loops that, together with the multiplier of teams across the aisle all working with each other, deliver value at a rate we've never seen before. By leveraging a culture of collaboration and more powerful tooling all along the Software Development Life Cycle, the next value unlock starts looking weirder and weirder. How weird?
Welcome to Whole-Body DevOps.
Introducing Whole-Body DevOps
Whole-Body DevOps is a holistic approach to software development that shields human attention across every stage, prescribing less complexity across pipelines and the developer's inner loop. It goes a step further by addressing the problems of weak telepresence (in tools like Slack and Zoom) as a problem of collaboration.
The point is to adopt the tools and practices to attain and sustain meditative absorption. This is the whole body focused to a single point and it's known in the west as Flow.
Whole Body DevOps seeks to address the whole body of the DevOps practictioner. This whole body encompasses the entirety of a practitioner’s experience, physically and virtually, including the sphere of human attention and feeling.
I wear a VR headset to block out extrasensory stimuli where I hang suspended in the galactic void with three virtual monitors. It's like turning on Focus Mode in your code editor but for your entire visual field. With the headset on, my focus occludes anything but my cockpit of IDE windows. Fujitsu commisioned a study that showed productivity gains of up to 35.5% when using multiple monitors.
.gif)
More than a plethora of lightweight displays wherever I go, VR is a Whole-Body practitioner's ticket into shared spaces of embodied presence like Mozilla Hubs. A study published in January 2022 by a coalition of researchers from three universities in Finland found virtual spaces boost team cohesion.
Flow in the inner loop
Flow is the quality of effortlessness that girds creation. Wikipedia defines flow as, "the mental state in which a person performing some activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity."
At KubeCon + CloudNativeCon Europe 2022, I interviewed our co-founder at garden.io, Þórarinn Sigurðsson, where he related a story of flow and how tools like Garden support the conditions necessary for flow:
When I was a kid there was a cartoon on TV where a boy who had a magic chalkboard would draw a bird and the bird would fly off the chalkboard but that's what programming feels like at its best: you come up with an idea and then it animates itself magically before your eyes. When the tools get of your way and you can see the results of your thought immediately, that's the magic.
Flow is an innate human capacity so many of us have lost even the memory of once possessing.
Because flow is an intangible state of human attention, there are no guaranteed methods for its entry. Whole-Body practitioners may be a family working remotely from home with children or work in an environment of stressors that all present their unique challenges to entering flow. The author has had particular success with monotasking, meditation, and demarcating areas of a workspace "attention zones" together with the aforementioned VR technologies. Your organization may benefit from practices such as Calendar Zero or other practices from Cal Newport's Deep Work.
Reproducible developer environments
Reducing complexity across the software stack by choosing fewer, more comprehensive tools across fewer platforms is another maxim of Whole-Body DevOps. Whole-Body DevOps approaches the technical problem of complexity by thinning the boundary between a developer's inner loop and production and reducing the cognitive load of many tools down to just a few.
Reproducible developer environments are holistic developer environments that comprise all of the tools a team needs to get started developing. Developers should be able to instantiate an environment with one command and get to work. I make use of Development Containers. Dev Containers are just container images with decorations: they're comprehensible because writing them is similar to how we execute commands in a Unix shell.
An alternative to development containers is Nix, a wholly self-contained way of describing all inputs and outputs of any given thing, such as a developer environment, and guaranteeing portability and reproducibility. Because Nix throws out most of the conventions we have around filesystems and disrupts the mutable mess of building and packaging the industry does today, most Nix-things are treated as colorful curiosities to be distantly admired.
One way of abstracting the alien patterns of Nix is Devbox developed by jetpack.io. Devbox not only allows you to develop without virtualization on macOS, but if still need to emit an OCI-compliant container image for delivery, you can with Devbox. If you're not running VS Code but an editor of less popular mindshare like Emacs, Nix and tools built on top of Nix like Devbox, are a powerful choice.
Holistic developer productivity engineering
The Developer Productivity Engineering (DPE) Handbook describes its discipline as a, "software development practice to maximize developer productivity and happiness". It takes, as its field of optimization, toolchain effectiveness and accelerating CI/CD pipelines, among others.
Whole-Body DevOps encompasses the tools and methods of the Developer Productivity Engineer with a particular focus on technologies and practices that condition flow states. Because it's Whole-Body practitioners operate on the level of the developer as a whole human being with all their intangibles of feeling. One may, a rationalist, a learnéd person, believe feelings are things best left to the Realm of Woo Woo but this is more division among parts.
Recruiting the whole body of the developer into focused, collaborative work is key to Whole-Body DevOps.
It may appear a nuisance to some organizations to treat these intangible components of a developer as integral to the whole yet the biggest mistake since the birthplace of the corporation has been pretending one human walked into their workplace (virtual or physical), and another walked out.
Why adopt?
To recap, Whole-Body DevOps is DevOps with extras:
- Fewer, more comprehensive tools
- Reproducible, comprehensible developer environments
- Practices that support developer health and flow states such as monotasking and Calendar Zero
- A loosely interconnected grouping of present and future technologies that facilitate focus by recruiting the practitioner's whole body, virtual or physical
When onboarding is as easy as handing your devs a single tool with the argument equivalent of up that also outputs production-ready artifacts ready to launch you're practicing a component of Whole-Body DevOps.
When you then enshrine the sanctity, the truly holy quality of attention in your developers, with practices to support their absolute absorption in any particular task, you are practicing two-thirds of Whole-Body DevOps. When you begin to address the unique challenges introduced by remote work by leveraging current and future technologies to support a developer's presence within teams and company at large, you are practicing all parts of Whole-Body DevOps.
If Whole-Body DevOps rings true for you, why don't you join our community at garden.io/community and contribute with your ideas. We'd all love to hear what you think makes for a Whole-Body DevOps practitioner.
[Heading image: "Kusōzu: the death of a noble lady and the decay of her body. Watercolours." Credit: Wellcome Collection]
