Battle for life
In his last published book[Battle12], Christopher Alexander showed how powerful the systemic forces are against the pattern movement. The book recounts the events before, during, and after the construction of the Eishin Campus. He began by explaining the existence of two systems—System A, which is the timeless way, and System B.
System A is the way of reviewing the lay of the land and the requirements of the people[Battle12]. This was his system. I suppose he called it System A because, in some way, he felt it was the original way.
System B is the money, ego, and image-driven approach—the system of rules and regulations imposed from above without humanity. System B was and is the predominant way we build things in the modern world.
The book recounts the setbacks and successes when working in System A. The Eishin Campus project was a school construction project to be carried out in Japan by Christopher Alexander’s team. System B did not defeat System A on the Eishin Campus project, but it did leave a mark, reducing its value and strength. System B fights a dirty game. It is a robust survival system. Money drives it, and money has no morals. There is an account of an event[Battle12] that starts as a recommendation, then a bribe, then a death threat to get rid of Christopher Alexander, his team, and their System A approach to the development.
System B protects its interests through whatever means are at its disposal. We know this to be accurate because we hear far too many tales of how large corporations will consider illegal behaviour if the fines are less than the cost of doing the right thing. We know people protect their way of life and are inherently risk averse. System B, being a system of people and money interacting through contracts and requirements, is only beholden to financial risk. Systems theory would invite us to make many strong assumptions about the behaviour of such a system.
Christopher Alexander made some strange observations during the project. One such observation was the ineffectiveness of System B—not inefficiency, but the inability of the system to produce the best possible outcome given what was available. System B lacks trust and only allows those in charge to know things and make decisions. To maintain control, many feign knowledge rather than be caught out as fallible. This leads to waste and ineffective processes.
In one example1, there was a call for stone slabs for the paths between the school buildings. The System B contractor on the project claimed the paving would be too expensive as the required quality would be beyond their budget. When the System A team suggested a rougher quality paving, the System B contractor shot down their idea and claimed absolute knowledge of the requirements and materials. Either on the off-chance or in a fit of diligence, the System A team went to a stone yard to determine if they could find something of a compromise. There, they encountered an expert who suggested their original rough-hewn stone would be good enough for the paths. The expert further reinforced the point, making reference to the yard where they stood. They claimed the lorries had come back and forth over it for many years and added that it was laid with the very same rough-hewn stone. Strong enough for lorries, let alone students walking between classes.
System B is very sure of itself. It knows. It does not think. It can make decisions quickly and offer certainty even where none exists. Confidence can be compelling when your goal is clear and you want to know whether you can afford to complete the project. We will ignore the fact that System B almost always overruns its budget anyway, as it does not allow for late-stage adjustments. But the allure of certainty is a positive feature of the system.
During the project, system B defended itself further by causing setbacks and even making it so the project could never be fully completed[Battle12]. However, the benefit of System A is that even an incomplete project is usable, extensible, and repairable at a later date. The project was a massive success, despite all the damage dealt to it. The campus was known as a wonderful place, even in its incomplete state. Teachers and students alike found peace there like nowhere before. System B did not defeat Christopher Alexander, despite all its attempts.
However, System B did manage to defeat the design pattern movement in software. In building construction, System B was the establishment—the modern building method with contractors, suppliers, bids, and tenders. In software, the establishment did not need to fight back against the return or a natural process. In software, System B is the foundation upon which development practices were built. System B didn’t fight back; it did one better.
Subsumption
Something consistently happens in new technological ventures after the honeymoon phase, where the technology is new and exciting. People become annoyed that the successes aren’t fully repeatable. They want to understand where things go wrong. They want training. They want some structure to control and manage it so future usages of the technology are successful. Some people gain more experience than others and become trainers and teachers. Those with good track records—or at least the ability to convince other people they have good track records—set up consultation services. When there are too few consultants to go around, the consultants start training consultants. And that’s how certification programs begin. This is the System B of software (and any other technology or engineering industry, in my opinion), and these are its patterns of reducing the ability of any new process to fully replace command and control.
But notice something strange here. The first step on this path was when people blamed their failures on lack of training, not the new technology. Not everyone did. Some immediately decided the technology was at fault and continued on their merry way. They needed no more interaction with the technology to know it was not for them.
Command-and-control is the game we play of holding onto power and controlling a workforce to achieve our goals. When the way of working suggests giving up power, command-and-control defends itself. It does this by compensating anyone with compelling arguments that they can provide the same benefits as the new hotness without giving up the power to demand a specific way of working. As per the building construction industry version of System B, financial rewards play a tremendous role in what will drive the outcome.
System B heals itself from attack by paying to convince the workforce they are in System A, such as when we are forced to follow processes tagged with the term ‘agile’, when they are anything but. Even open-source development is not entirely immune to this, as the belief system created by System B is contagious.
Even though I’m not aware of any direct death threats in software development, something similar happened. Some light has been snuffed out. For something to die, it merely needs to have no impact. To be silenced is enough. To be firmly and enduringly misrepresented is enough to kill an idea.
When the way you are measured and evaluated is baked into a contradictory system, the result will be skewed. Grading science papers on use of colour and word choice is useless; just as useless as Christopher Alexander found the classic approach to appraising students of architectural colleges. When the establishment measures your new work through an old and trusted lens, their judgements are often taken as valid, even when inappropriately applied. Refutation of value by a trusted source is enough to stop many from reviewing the content further. In all domains, the patterns movement has been under conceptual attack.
Death is the removal of influence
The Agile movement suffered the same fate. Hundreds of Agile coaches have certificates from expensive courses on how to whip teams into shape and do Agile at scale within a framework. There are Scrum trainers with many years of experience getting development teams to follow the Scrum process to the letter.
Most, if not all, the original authors of the
As I write this, DevOps is starting to suffer the same fate. Many developers
turned Eliyahu Goldratt’s thought-provoking information in
The front cover picture of any DevOps presentation talks about joining the forces of development and operations, but that’s only a visceral symptom of the principles. The core of DevOps is about giving power to those closer to the problems. It’s a process of looking for bottlenecks, understanding them, and finding ways to exploit them. The word exploit would take some explaining, but this is not a book on DevOps, so I shall leave that for you, dear reader, to discover by yourself.
How you fix the bottleneck is a solution you come up with. That is, empowering those at the site of the work to solve the problem by making it visible. DevOps is not a solution; rather, it’s an ongoing process of sensing, analysing and improving things.
But we’re starting to see the meaning of DevOps dissolve into different things. Some DevOps roles are just a different nameplate on someone who knows how to start and stop servers. Some DevOps courses are solely about how to run Kubernetes clusters. There’s no teaching of the process of analysis of existing structure2. It’s as if someone studied several software shops and decided to sell the least common denominator to everyone else.
This is a deep poison. DevOps was aligned with learning how to find the real problems and how to discover or build specific, well-fitted solutions. Hmm, that sounds like someone I know. But it’s been wrangled into a collection of generalised solutions that proved to work several times. Oh no!
Platform Engineering is taking over the part of DevOps relating to creating better working practices, but what does that mean for the value of DevOps as a way to review your situation? Workers won’t conduct the analysis, and we will lose valuable insight into our processes. Gemba Walks3 will have to be undertaken by non-management (the platform engineers), and then things get clumsy and complicated to sign off and authorise, as the cost will warrant management’s attention. It all seems doomed to eventually become consultation again. DevOps will lose influence, and then the next thing will replace what we lack because we tried too hard to do one thing and unbalanced another.
System B appears to prefer to try out every possible silver bullet rather than face up to the idea that management is a job in which you need to pay a lot of attention to how the work is done while also giving up your power to those you have hired as experts in what they do.
[Battle12] p. 301.
Management cannot improve the process without seeing it happen, so Toyota used to have their managers walk the gemba, the place where the work was done, so that they could experience the actions and pace of the real things happening.
There is a training course for Eliyahu Goldratt’s Theory of Constraints called the Jonah program. It teaches you how to analyse a production process in the same way the supporting character in The Goal did for the protagonist there.