Software design principles for teams: The Principle of Intentional Experimentation.
Open your codebase to new approaches to design… in a controlled, contained and collaborative manner.
Background
This is an elaboration of one of the principles I originally published in the following article…
Principle
Open your codebase to new approaches to design… in a controlled, contained and collaborative manner.
This principle is heavily inspired by the great article “Choose Boring Technology” by Dan McKinley (https://mcfunley.com/choose-boring-technology), and specifically the reference to “innovation tokens”. The notion of tokens (alliteration intended) both supports and constrains technical experimentation, which is at the heart of this principle.
Let’s say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. You might get a few more after you achieve a certain level of stability and maturity
The very existence of such tokens speaks strongly to the idea that experimentation is a first class activity within the team. Experimentation sits alongside stories, builds and deploys as “things which matter”.
The constraint on the number of tokens enforces the discipline that balances forward-looking speculative exploration with pragmatic care-and-feeding of the existing codebase. This forcing function operates much like work-in-progress (WIP) limits on Kanban boards, albeit on a longer time-frame (e.g., a month, a quarter, etc).
The above image of poker chips was chosen deliberately because these experiments are bets, rather than sure things. You might find a better way to handle state in React without using Redux, but you could conclude the benefits of alternate approaches are not worth the switching cost. You might choose to investigate different approaches to testing your IaC, but decide you would rather invest your remaining token on building a new microservice using an experimental service template produced by another team.
Ultimately, the Benevolent Dictator plays a key role in ensuring the team finds the right balance between being too conservative and too cavalier in it’s approach to technology innovation.
The act of conducting experiments has an interesting range of pros and cons. On the positive side:
Can be a (short-term) morale boost to the team
Some team members might be especially passionate around this form of work
A successful experiment will result in an observable improvement to the codebase, or the tooling supporting the codebase
Running experiments are be a great leadership opportunity for junior engineers
Conversely, there are a non-trivial set of negatives to consider:
As mentioned previously, the outcome of any experiment is unknown. Unsuccessful experiments produce knowledge, but no benefit to the codebase
Experiments take time and attention away from business-as-usual activities
Prioritizing experiments within a token-constrained environment is hard
Evaluating the success/failure of an experiment can be extremely tricky
You can assess how experimental a team has been by looking at the tech stack they use. Rampant, unchecked experimentation reveals itself in a pot pourri of similar options in tooling and approach scattered throughout the codebase. Different approaches to testing, configuration, modularization, etc will be obvious when inspecting the code.
On the other side of the experimentation coin, the codebases of overly conservative teams may initially present in a much healthier state. These codebases will be far more consistent, with very little variety in approach. There will likely be little contention within the team about how things are done. The biggest sign of the dysfunction in such teams is the lack of experimentation, which could be motivated by external factors like delivery pressure, or internal attitude due to lack of interest or fear of failed experiments.
Tokens provide the affordance for disciplined experimentation, but the tech lead must address the external and internal factors which contribute far more significantly to a team culture that takes the need for such experimentation seriously.