Unresolved Forces - Copyright Richard Fabian 2024

Agile principles emerged when like-minded individuals observed management’s response to the software crisis in their organisations and the workplaces of others. It was a response to those regressive actions and was a solution centred around practices that were conceivable at that juncture. The strength of the Agile Manifesto[AM01] stems from a particular lack of strictness about its solutions. The presence of simple preferences over laws solicited many interpretations and made the migration more palatable for managers who wished to continue commanding and remaining in control.

Because the link was weak, the Agile movement did not incorporate various aspects of Christopher Alexander’s theories and processes. Some remain missing because the movement never introduced them, but others are missing because they faded away. Perhaps they disappeared because we failed to understand their value, so these activities were not deemed worthy of protection. However, a more potent force may have removed them intentionally.

The demand for fiscal control was only minimally adopted. Agile development has almost entirely dropped this element now. The practice of bringing the customer into the work process has diminished along the way, with many contemporary interpretations of Scrum¹ assuming product-owners to be both sufficient and necessary while neither is true. Many other aspects of feedback garnered through presence at the site have been lost, and the approach of taking small steps has been diluted into sprints or iterations of delivery rather than opportunities for direct and instant feedback.

Although we cannot trace the Agile Manifesto directly back to Christopher Alexander’s work, the recognition of software design patterns can. Indeed, the concept of software patterns may have lain dormant for decades had it not been for Ward Cunningham and Kent Beck picking up on the connection in 1987. They approached a design problem the way Alexander did by developing a language for the project. They used patterns to guide novice developers². This original work on design patterns in software development was more closely aligned with Christopher Alexander’s processes, and the simple pattern Collect Low-level Protocol was closer to an Alexandrian pattern than any of the GoF’s examples. Deviation from the principles of A Pattern Language[APL77] is one of the reasons why design patterns failed in the way they did. But this chapter is not about failure. That’s what the following one addresses.