“Complicated” and “Complex”
What does “complicated” mean and is there a difference to “complex”? Often the two expressions are used synonymously: “complicated” equals “complex” equals “not simple”. What distinguishes the two terms and why does this play an important role in the context of agile approaches?
What is meant by the term “complicated” can be explained very well using the example of complex manufacturing processes, as they occur in industry. They involve a variety of simple individual steps that must be performed in a specific order. In many places, a coordinated use of people and machines is necessary to complete a partial step. Ultimately, neither the large number of steps, the observance of the sequence, the use of machines nor the necessary time change the fact that the individual steps, apart from their temporal classification, do not affect other steps. They can be viewed and optimized in isolation. This characterizes a complicated process or system.
In contrast, a complex system is defined as follows:
Complex systems are systems (assemblies of objects that are in a holistic context and are delimited by the interrelationships between them from their environment), which refuse simplification and remain multi-layered, Wikipedia.
A central element is therefore the inability of a system to be simplified. The attempt to change an object of a system directly affects other objects of the same system through this intervention. Mathematically speaking, I can’t change a parameter without affecting other parameters. The parameters are not independent of each other. An optimization of the system cannot be done trivially by optimizing a single parameter, detached from the rest.
In modern software development, one has come to the conclusion that it ultimately behaves like a complex system and not like a complicated one. There are many parameters such as customer wishes, technical boundary conditions, temporal boundary conditions, monetary boundary conditions, etc. in play and most of these parameters also influence each other. Although there are often rough feature or product ideas in product development that are initially available, many details of the software to be created are unclear. This is due to the fact that there are so many different ways of use and types of use in a significantly extensive software that advance planning would represent a time expenditure that is unacceptable because, for example, a competitor would have already placed a product ready on the market in the same time. During implementation, new insights and ideas for further features often arise that simply did not occur to anyone in advance.
This is similar when creating applications on a project basis for a client: he often does not have the knowledge to be able to answer every detail in advance. The questions during implementation bring important open points to light, which significantly influence the characteristics of the desired application.
The modern agile approaches have been conceived precisely for this type of development project. They are made for complex environments. Using agile methods in non-complex tasks can still be useful but tends to miss the mark. Anyone who uses agile process models to increase efficiency, for example, has not understood this and/or has been wrongly advised.