Unresolved Forces - Copyright Richard Fabian 2024

These elements he listed interfere with the wholesome process of physical construction. In some projects, he tackled some of these problems head-on. In others, he avoided them by careful selection of clients. Fixing the process and removing all the impediments might not be possible in many lifetimes. But knowing it can be better is step one. A better software process is possible. One that is agile allows for a more effective introduction of DevOps practices and creates better products with fewer resources.

If we look to Alexander’s list for inspiration, many elements can be brought across wholesale into software development. Some of the items on the list need conversion from the domain of physical architecture to development. Have a go yourself, but here’s one attempt to produce a list of elements inhibiting software development using copies, adjustments, and additions to Alexander’s list:

• The control and regulation of money
• The way money flows through a project
• The process of development
• Copy-paste, asset flip, and trend-chasing development
• Publisher/client contracts
• The role of designers or project managers and engineers
• Organisation of development studios
• The nature of planning
• The nature of master plans and schedules
• The process of moral and political obligation
• NDC, GDC, FOSSDEM, PYCON, CPPCON, and other big events
• The size and scope of software architects’ or designers’ work
• The teaching of software engineering
• The priorities of tool providers
• The lack of anything akin to building codes and regulations
• The role of vendors and platform providers
• The process of purchasing software
• The distribution of authority to make decisions
• Patent law

What this tells us about our problem is that you must apply systems theory to achieve anything lasting. There are too many elements that will push back against a change. Each thing alone is not to blame, but combined, they are a formidable force. Each brings a small policy resistance effect. Each brings a sense and feedback leading to actions undoing your work.

To resolve the problems with agile processes, we must find a way to make the good side of Agile visible to those who need to relinquish power. Who are they? Look at the list. They are schedules, contracts, money flow, and trend-chasing, and even events play a role.

When your organisation tries to keep every developer busy rather than keep the development pace at maximum, you have to look at what forces people to look busy rather than be effective. Those things are the roles we play, the size and scope of the projects we are on, the contracts we write, and even how we decide how many hours we work and how we evaluate and compensate developers.

As a concrete example, the above elements create a weird incentive to work slower. Most management punishes workers for working fast. Don’t believe me? Well, consider this: if I, as a worker, can finish a job in half of the time you expected it to take, you would most likely wish to pay me only half of the price for the job. We expect to pay for work by the hour, regardless of its value to us. But, if the work is completed satisfactorily in a fraction of the expected time, and simply not delivered, an employer would be none the wiser and would willingly pay the full amount. You would receive the product later than you could, and still be willing to pay more. Something is very wrong when we reward people for doing a worse job or taking longer to complete a task.

We need to concentrate on the inhibiting elements. The workers are fine. It’s the rewards and expectations that are broken.

Moving beyond image-driven

As an example of fighting the antagonistic forces, perhaps we can think about how to address the elements involved in the image-driven construction process. We know much of what was before must somehow be preserved. What makes up our day-to-day work and the necessities of development must be kept. The image-driven process is linked to the movement of money, rewards, contracts, and the size and scope of projects. Without the image-driven approach, it might be impossible to maintain large teams doing massive projects. But is that a problem, or is it an indicator of the unsustainability of our process?

How could you create an airport without some big-money investor driving the process? An airport is desired by those running airlines. It is also wanted by those wishing to travel or ply their trade by air. As a second-order effect, it is also desired by those wishing to set up shop within or near the airport for commercial trade or to offer transport services. Many people want the airport so they can provide goods and services to those who use it. But even with all these people hungering for it, who would build it without the up-front money to buy labour?

The answer must be those who want it. But how can so many small actors drive the creation of a thing as large as an airport without it causing them to go bankrupt before it’s finished and worth anything to them? A small newsagent can’t wait five years to sell their first newspaper to the first transatlantic traveller. A taxi firm cannot invest in hope of passengers who won’t book their first ride until the owner’s newborn has spent their first day at school. Surely, waiting around for an airport to be complete cannot work.

Perhaps we’ve missed something important. We’re assuming the airport needs to be completed to be valuable. This is the same assumption people often make about evolution. They ask, ‘How can eyes or wings evolve when partially finished eyes and unfinished wings are useless to the creature?’ to which we respond that unfinished wings make rather good parachutes, and partial eyes still warn you of overhead predators.

The default position of creating the product in one step is an emergent property of how we work now, where the big-money option is present. Do we need to build a massive international airport in one step? Or do we make a smaller one that serves the local people and expand it over time? The development must start from a worthwhile first step, and each step must lead to a better airport.

Perhaps instead of a gradual change in capacity, we co-opt something else. For example, one of the busiest airports in the world, Heathrow Airport in the UK, started as a small airfield, was developed into a larger military airport by the government during WWII, and then switched to a civil airport as the war ended.

The largest airports in many countries started as small ones. One runway turns to two or three or more. Land needs to be bought and developed upon later, which can be painful, but not fatal like a half-finished, overly expensive project. And, if the needs of the people change, the plans change, and losses of a grand scale are not realised. It is better to have an expensive but safe path to expansion than a cheap and efficient path to ruin.

The distribution of authority to make decisions

The management of anything needs to be at the correct scale. Making rules for the layer below is usually allowed but often a bad idea. Local decision-making works at many scales. The gardener knows best how to make their shed work for them, and the chef knows how their kitchen should be. The mayor knows best what building to construct or whether to spend taxes on road maintenance. The government knows best how much to spend on health care or the military.

But only at the correct scale. The state or country might know how much to spend on the military, but they wouldn’t dare specify how much to spend on bullets. The chef might know the kitchen but cannot be trusted to know how much should be spent on funding health and safety inspection organisations. Everyone says the correct standard is just a little less than what they are doing.

Big government isn’t bad because it’s large. It’s ineffective when it imposes rules outside of its locality of scale. When anyone makes decisions outside the scope of their day-to-day understanding, where they cannot feel the pinch and pull or pressure, they will make mistakes. When anyone makes decisions where they are the direct beneficiary, the decisions cannot be made disinterestedly.

Even when intended to protect, rules imposed from above often cause harmful downstream effects. Imposing local laws at the global level does not work either. We need to distribute decision-making authority to those able to enforce it through local wisdom. And we need the wisdom to know which domain is local and which is remote.