Thank you for your excellent comment. Here is what I think.

1. The complex system for a software project includes almost everything: people, software application, technology, process, environment and customer’s needs. This system can exhibit self organization and produce optimal results and avoid unlimited trials. Some arguments:
* fitness criteria and constraints (time, money, requirements) substantially reduce range of acceptable system states
* software development best practices, empirical theories and approaches (e.g. Agile) help with selection of optimal states and strategies
* software team can experience short cycles within one project that allow to learn, adopt and move to the new better states before the project finish

2. Yes, I believe developers should make implementation decisions. Developers don’t work in isolation. Cohesiveness of the application will be not impacted if
* developers frequently synchronize their ideas with customers and adjust based on feedback and overall concepts (evolved together)
* the application subsystems continuously integrated and tested as the whole that quickly spots misalignments and conflicts
* developers constantly interact, brainstorm and pair to find the optimal solutions for the subsystems and the application

3. Emergence in the software project system means appearance of the previously unobserved behavior, roles, ideas and even goals based on interaction of active elements (people) with passive (project needs, methods, technology, domain, the developed application) and external world. It is simplified interpretation, but I think it is not too far from Wikipedia definition.

Does it make sense?

Perhaps you can point out what is fundamentally different between these definitions? I am particularly uncomfortable with the FAQ’s claim that an engine is an emergent system. An engine is not a collection of self controlling components, and it is not self organizing. It is a designed system of components specifically configured for one purpose.

I was similarly confused by what you were proposing. I am unclear whether you were saying the software, the development process or the developers themselves were the components of a complex system? The software itself seemed the least likely, as the engine analogy holds true here as well. While each unit of code can potentially be used in multiple places, the overall structure of the software is designed. It is meant to have one set of functionality, and if through emergence it displays other behavior that should be considered a bug.

If you are referring to the latter options then I would say that, as my understanding goes, self organizing systems fitness is based on iterative attempts. In agent based software this is simple rules for agents and the results when introduced to an environment in large numbers. In genetic algorithms this requires many ‘generations’ of attempts to solve a problem. If these concepts are carried over to software development then perhaps I would agree that a nearly unlimited arrangement of software development teams over a period of time would produce many versions of an application, some of which would be better than an architected counterpart. However, while this model may exist to some degree in systems such as Linux features, it is not in practice or even arguably cost efficient within a single organization.

You seem to make the point that each developer should decide how to implement their own subsystem. I do not subscribe to the theory that architecture removes decision making from the developer’s duties, but to the one that an architecture is an overarching set of constraints that directs the development of the software. An architect would for example; choose an OS, programming language, hardware, database and perhaps software framework or design patterns. If each developer on the team was not so constrained, it would be extremely difficult to produce a cohesive application. In many long standing teams such things are foregone conclusions, but that does not mean the decision was not made.