Take time to look around for inspiration. That's how I concluded my last editorial. Given recent events, it's a good theme to continue with.
Ritual: A solemn ceremony consisting of a series of actions performed according to a prescribed order.
Solemn: Formal and dignified, serious, deep sincerity.
Whether we reference SolarWinds (https://www.microsoft.com/security/blog/2020/12/18/analyzing-solorigate-the-compromised-dll-file-that-started-a-sophisticated-cyberattack-and-how-microsoft-defender-helps-protect/), Boeing (737 Max 8), or those brave congressional staffers who had the presence of mind to take custody of the three ballot boxes before the U.S. Capitol was breached, for purposes of this editorial, the three are equivalent. With respect to the ballot boxes, indeed they're just physical things that contain physical things that can all be replaced. As to what those ballot boxes and what they contained represented, those things can't be replaced.
How do these all relate? Like all things, it's about context and the inexorable fact that at an abstract level, everything relates to everything else. Everything in a given context is interconnected. In other words, actions have knock-on effects; some are intentional, others are unintentional. And depending on your system's complexity, a small change can have dramatic downstream effects (AKA the Butterfly Effect). The degree to which the system and its underlying processes are understood well are the best defense to unintended and undesirable consequences.
Separately, there's what each of us believes and there's what each of us does. There is that oft-quoted phrase: Don't pay attention to what they say, pay attention to what they do. The latter is objectively verifiable with our own senses. The reasoning is simple: Mindreading isn't a real thing.
Think of the last time you advocated for a particular outcome. In any competent and rational business and technology environment, you'd be required to provide evidence in support of your conclusions. In other words, there's what you believe and there's what you can objectively prove.
So then, how is the concept of ritual relevant?
In all cases, it gets to what we're defending against: the loss of trust and confidence. Everything boils down to integrity. For any system we build to have integrity, there must be rules, order, and sound processes. One of my favorite phrases is People, Process, and Tools. In other words, we must first have the right people. From there, we can build a process. And then finally, once we have the right people committed to the right process, then, and only then, can we employ the right tools in furtherance of efficiency. And what device, whether explicit or implied, do we invoke to carry on these ceremonies that involve people, processes, and tools? Ritual.
Things like SOC (System and Organization Controls) - and the ritual and ceremony it requires - all have a purpose. Read any annual report (10K), specifically item 9a, Controls and Procedures. Documented rituals and ceremonies with documented performance are your positive objective evidence that you're doing things correctly. Alternatively, you can make claims about what you believe is or what was done. Making a claim doesn't make it so, nor is it evidence. To meet that burden of proof, there must be work, hard work, and coordinated work among many people and the description of what work was performed by who and when must be a by-product of the work.
Assuming that there's a codified process, how does that get performed in a systematic, repeatable, reliable, and consistent way? Mature processes yield positive tangible results via actions that are carried out in some prescribed way and are done in a serious manner - and not only in support of the work at hand, which is to build and deliver software. It's also about telling the story of what that work entailed. Agile principles coupled with the Scrum Framework is a good example of a ritual that can support what SOC (referenced above) requires.
But just going through the motions of Scrum ceremonies alone isn't enough. Each individual person on the team must believe and be committed. The team members, collectively, must have a shared sense of purpose. Fidelity to that is what makes any ritual or process worth anything. That fidelity to task, the ability to make that apparent to those outside the process, doesn't just happen. Regardless of whatever tools are thrown at a process, the one thing that can't be faked or accelerated - is the concept of time. Time in this context has two perspectives. The first is the people who used to occupy the chairs held by others now. This is an organization's history and the foundation everything that follows. I suspect that the staffers guarding the ballot boxes had a sense of, benefited from, and were prepared because of that history. Watching them on TV, there was a sense of confidence and resolve in their custodian role. The second perspective is focused on the present and what must be confronted now. Every problem to solve requires its own time. Anybody who has read the Mythical Man Month knows the lesson that “throwing bodies” at a problem doesn't work.
Building trust and confidence, rather than coding or design, is our ultimate job as software developers. We build that confidence through demonstrated performance that itself is verified through evidence. The important thing at the heart of it all is how we carry out our work, the principles, patterns, practice, and above all, the ethos, duty, and fidelity we bring to our efforts in furtherance of carrying out our work. The burden is on us to instill that confidence in others, the ones outside looking in. If we don't, we end up with a trust gap.
We can learn from the Arts and Crafts movement from the 1880s-1910s. That was about the dignity of work that arises from being true to the craft as well as the recognition and respect from the organization that realizes the benefits of such labor. The tools we employ to carry out our work, those are part of the ritual. To wield them artfully, we must understand the processes of our craft.
Tools are not the craft. CODE IS NOT THE CRAFT. Tools are the means by which we practice the craft, and code is a tool. Diverting to my law persona, my practice of law doesn't depend on tools like WestLaw or LexisNexis for legal research any more than I require any specific software tool or language. Certainly, tools help and some tools, depending on the context, are better than others. Legal research (a process) is a necessary component of law practice. It's no different than the code we write. At a certain level of detail, there are many ways to write code and there are many ways to conduct legal research. The aforementioned tools (WestLaw and LexisNexis) are very efficient. However, if I didn't have access to such tools, I could still rely on the books. You've seen them in any legal drama - the impressive array of published court reports and statutes. These books are available for free in the law library of your local municipality. In the abstraction hierarchy, this is about as close to the metal as it gets. You never know when a given tool may not be available. There's still a job to do. Of course, at some point, we'll hit a performance wall once basic elements, like the Internet, are no longer available. How well do you know your processes - independent of abstractions? An abstraction based on a process you don't understand is useless. And the decisions made therefrom can be quite costly.
Ritual is a means by which we can learn, apply, and eventually master our craft. A somewhat popular movement these days is the Software Craftsmanship movement in its many variations. Andrew Hunt's “The Pragmatic Programmer” posits that a developer's professional development should be akin to the medieval guilds. Established rituals are a means by which knowledge is effectively transferred. Think of the apprenticeship programs in trades such as plumbing or carpentry. And no, the fly-by-night coding bootcamps that promise to make somebody an employable software developer without prior experience isn't that.
The dev, test, and build processes by themselves, they're just processes. The duty, fidelity, and seriousness we bring to the work, that's what makes it a ritual. And that it's a ritual means that what you and your team does matters. That's people and process governed by inviolate overarching principles and fidelity to the task at hand. If you have that, find the tools that match up well. Be true to that ritual. And if some aspect of it must change for some reason, have a ritual for how you manage that change. If you just change rules, tools, etc. on a whim, that's just random chaos devoid of discipline, rigor, duty, and fidelity. That's amateur hour run by people who don't know what they're doing.
Your rituals are the means by which you can objectively demonstrate due care and performance. If your shop keeps running into the same issues, perhaps it's time to detach from the keyboard, stop, inspect, assess, and adapt accordingly. A good way to start may be to take a healthy look in the mirror. If ritual, duty, and fidelity to the task at hand is deemed to be a budgetary non-starter, you should ask yourself what exactly it is that your organization is doing and why you think sticking with the status quo will lead to a different, better result. That's the very definition of insanity in which we hope to obtain a difference result based on the same actions.
JP
