Traditional models of software development uncritically mimic the organisation structure formed during the long history of second industrial revolution, associated with the names of Ford and Taylor. The stress on modular development and reuse update software engineering models in order to increase the degree of variability that can be economically managed, but it rests on same concepts.

In this lecture I maintain that XP models of software production rest on an entirely new “technology” of the process, that asks for a breakthrough in organisational concepts supporting it. Part of those concepts can be found in “Japanese style” models of manufacturing and factory organisation, that greatly succeeded during the decades 1970 and 1980 (Coriat, 1991); partly are completely new, and help to advance in the understanding of what a “post-fordist” factory could be. While in the past, software engineering was an awkward imitation of manufacturing models, presently XP can lead manufacturing and service producers toward the building of an eXtreme organisation, the one which can cope with the growing variety in demand and permits to fully exploit flexible technologies of production.

In the first part of the lecture I will resume basic organisation problems faced by a production system. Organisation structures help to manage complex production systems giving order and structure to three kinds of flows, needed to support the complex interdependencies arising from a production flow: information, decision and knowledge. I will show how fordist organisation succeeded in supporting a process and product decomposition that dramatically reduced the variety accepted by the system and stressed the importance of economies of replication, with a coherent organisation design that univocally maps the three organisation flows (information, decision and knowledge) needed to build up an infrastructure for co-ordination.

Different paths were followed in order to adapt manufacturing production systems to the emerging variety of needs. Among them, one of the most successful – widely adopted in software industry – was rooted on the concept of modularity. Modular production preserves the stress on replication economies and standardisation, but looking for a better trade-off between replication economies and adaptation to variety. This new infrastructure for co-ordination limits standardisation to a minimal set of variables (interface standards), decoupling both static and dynamic adaptation of subsystems by “information hiding ” (Parnas, 1971). This way to cope with complex production system has a long tradition, rooted in Simon (1996, 3rd) and Alexander (1964), and was enthusiastically adopted by software engineers. But emerging interdependencies and “imperfect hiding” (Devetag and Zaninotto, 2001) proved modularity and module reusability a less manageable tool than it was hoped and a unique and coherent pattern for information, decision and knowledge flows supporting modular decomposition proved to be unaffordable.

The way taken by software engineers with X-Programming rests on completely different instruments of complexity management. While fordist standardisation (and modularity) stressed a design aimed at reducing complexity by affecting the dimensionality of the design, flexibility and XP, while leaving a high degree of computational complexity, act on irreversibilities. Reduction of irreversibilities is obtained by methods which reduce adaptation and integration costs, and methods aimed at delaying irreversible actions. Less irreversibilities mean that to manage uncertainty a less hierarchical decision structure is needed. On the other side, dimensionality of production system, both static and dynamic, is still high (and possibly increases). This requires speed and efficient methods to transmit information and knowledge. As for information XP rests on concepts like local information transmission and the spreading of local adaptation. As for knowledge, search and experimentation patterns are co-ordinated by methods helping knowledge sharing. Finally, risks of misalignements are reduced by a tight control of timing (decomposition is leaded by timing rule, and not vice versa), which preserves a smooth flowing of the process, and of work rules, aimed at assuring a wide spreading of local knowledge. Finally, coherence is loosely assured by the adherence to meta, high level standards, which substitute the low level, interface standardisation.

Organisation theory helps to gain a better understanding of the rational of apparently dispersed prescriptions present in the cookbooks for XP. In particular, the opposition between actions on dimensionality and actions on reversibility highlights two different approaches to complexity management having strong consequences in the design of decision, information and knowledge flows. While this removes some flavour of magic from XP, it helps to: 1. understand to what software projects XP fits better: using various dimensions of complexity it would be possible to classify software projects in order to find a better fitting between the nature of complexity and the software engineering methods; 2. extend the logic of XP to other manufacturing and service processes: it is time, for software engineering, to stop mimic exhausted operation methods and to lead the way out of fordism.