Since the earliest times, human societies have been defined by their tools. Similarly, engineering teams are defined, empowered and constrained by the tool choices we make. In this talk, we’ll see how choosing common tools reduce cognitive load, enable reuse, and foster resilience in DevOps teams.
It can be said that early civilization is a direct result of the adoption of the simple, reusable, and highly adaptable stone technology used by our Paleolithic ancestors. A common platform (stone) and easily shared skills (knapping) empowered early humans to create all the tools necessary to survive and indeed flourish. Hunting, fishing, butchering, shelter, clothing, and early agricultural techniques were all made possible by the simple act of banging a few rocks together in a clever way. Moreover, the technology complex of early peoples enabled our first explorations of the benefits of failure: a mis-strike to a rock creates a new shape, a new tool… a useful flake.
Since then, of course, humans have created and adapted increasingly complex and specialized tools. Through each phase of growth, humans unlocked new abilities, reliable food supplies, resilient dwellings, longer life spans, and a higher quality of life by adopting more productive and efficient tools. As engineers we have come to recognize and appreciate the benefits of specialized tooling. Indeed, our modern DevOps growth is fueled by the maturity and adoption of many specialized tools: Configuration Management, CI/CD, The Cloud, Containers, and more.
While the tools we use and the tasks we accomplish have changed somewhat dramatically, many fundamental rules of tool use remain the same:
Tools are at their best when utilizing them can become second nature. Accelerating that familiarity is desirable as it optimizes the benefit of the tool. The simpler the tool, the easier it is to master.
Tools should be flexible. A tool used for a limited range of tasks is a tool unused and unmastered.
Tools used to perform critical tasks must be available to all. A tribe with a single garment maker will freeze next winter.
Tools are at their best when they spark new ideas, by freeing us from toil.
As DevOps practitioners, we are all familiar with the tension present around tools in our culture. We love working with tools, new and old, generic and specialized, clever and obfuscated. We are a tool loving tribe. Frequently however, that very fascination can create an explosion of tool adoption - every team, every engineer their own island of preferred ways to accomplish similar tasks. What is often overlooked, is how this fragmented approach to tooling is an anti-pattern in DevOps, creating barriers to collaboration, isolating teams in silos, and creating toil implementing the same method in new tools.
Standard approaches to tool selection tend to over focus on fairly narrow concerns. We look for precision, opting for the best of available options to accomplish the task at hand. In contrast, a less specialized, more familiar and common tool can deliver a broader range of benefits to DevOps teams. Interoperability, simplicity, familiarity, availability, and extensibility are the realized benefits for teams who adopt common tools.