All protocols are inherently “soft” in the sense that they are not physical, tangible entities. They fall on a spectrum of flexibility, with “weak” protocols at one end and “strong” protocols at the other.
Weak protocols are defined by their flexibility, openness to interpretation, and adaptability to changing circumstances. Rather than providing strict rules, they offer general guidelines that allow for a range of behaviours and responses. This flexibility is advantageous in situations where creativity, adaptability, and bottom-up coordination are crucial, as weak protocols create space for the emergence of new behaviours and solutions while accommodating diverse contexts and needs.
In contrast, strong protocols are characterized by rigidity, specificity, and prescriptiveness. They provide rules and procedures, allowing for little deviation or interpretation. Strong protocols are advantageous in situations where consistency, predictability, and control are essential, ensuring that participants follow the same rules and procedures. They are particularly useful in safety-critical contexts.
In human systems, weak protocols allow for the kind of organic, bottom-up coordination essential to complex adaptive systems. They create an environment that allow people to experiment, learn, and evolve practices over time.
Example of a weak technical protocol
In software development, the practice of writing readable code and including inline comments can be considered a weak technical protocol.
Readable code follows a set of conventions and best practices that make the source code easy to understand and maintain by other developers. These conventions can include using clear and descriptive variable and function names, as well as consistent code formatting.
Inline comments are explanatory notes that developers add within the source code itself to clarify the purpose, functionality, or reasoning behind specific lines or blocks of code. These comments are ignored by the compiler or interpreter, but serve as documentation for other developers who may need to understand, modify, or debug the code in the future.
What makes the practice of writing readable code and including inline comments a weak protocol is that it is not strictly enforced by the programming language or compiler. Unlike the syntax and grammar of the language itself, which are strong protocols that must be followed precisely for the code to function, readable code and comments rely on a shared understanding and consensus among developers.
There is no automatic mechanism that prevents a developer from writing obfuscated, uncommented code. Instead, the protocol of readable code and inline comments relies on discipline, training, code reviews, and a shared commitment to creating maintainable and understandable software.
This weak protocol allows for a degree of flexibility and adaptation to the specific needs and contexts of different development teams and projects. Some teams may adopt more extensive commenting conventions, while others may rely more on clear code structure and naming. The exact details of the protocol can evolve over time as best practices evolve.
In this way, the practice of readable code and inline comments illustrates the key characteristics of a weak protocol in a technical context. It is a protocol that is not rigidly enforced, but rather emerges from and is sustained by a shared understanding and consensus. It allows for local adaptation and evolution, while still maintaining a coherent set of principles that guide behaviour and collaboration.