In the agile community it is popular to use the terms *complex, complexity, complicated *many times interchangeably and and many times wrongly. These terms are many times *overloaded* with an agenda used to push a process or even a method.

First some definitions

**Complex**- consisting of many different and connected part. Not easy to analyze or understand. Complicated or intricate. When a system or problem is considered complex, analytical approaches, like dividing it into parts to make the problem tractable is not sufficient, because it is the interactions of the parts that make the system complex and without these interconnections, the system no longer functions.**Complex System**- is a functional whole, consisting of interdependent and variable parts. Unlike conventional systems, the parts need not have fixed relationships, fixed behaviors or fixed quantities, and their individual functions may be undefined in traditional terms.**Complicated**- containing a number of hidden parts, which must be revealed separately because they do not interact. Mutual interaction of the components creates nonlinear behaviors of the system. In principle all systems are complex. The number of parts or components is irrelevant n the definition of complexity. There can be complexity - nonlinear behaviour - in small systems of large systems.**Complexity**- there is no standard definition of complexity is a view of systems that suggests simple causes result in complex effects. Complexity as a term is generally used to characterize a system with many parts whose interactions with each other occur in multiple ways. Complexity can occur in a variety of forms- Complex behaviour
- Complex mechanisms
- Complex situations
- Complex systems
- Complex data
**Complexity Theory**- states that critically interacting components self-organize to form potentially evolving structures exhibiting a hierarchy of emergent system properties. This theory takes the view that systems are best regarded as wholes, and studied as such, rejecting the traditional emphasis on simplification and reduction as inadequate techniques on which to base this sort of scientific work.

One more item we need is the types of Complexity

- Type 1 - fixed systems, where the structure doesn't change as a function of time.
- Type 2 - systems where time causes changes. This can be repetitive cycles or change with time.
- Type 3 - moves beyond repetitive systems into organic where change is extensive and non-cyclic in nature.
- Type 4 - are self organizing where we can combine internal constraints of closed systems, like machines, with the creative evolution of open systems, like people.

**And Now To The Point**

When we hear complex, complexity, complex systems, complex adaptive system, pause to ask what kind of *complex* are you talking about. What *Type* of complex system. In what system are you applying the term *complex*. Have you classified that system in a way that actually matches a real system.

It is common use the terms complex, complicated, and complexity are interchanged. And software development is classified or mis-classified as one or the both or all three. It is also common to toss around these terms with not actual understanding of their meaning or application.

We need to move beyond buzz words. Words like *Systems Thinking. *Building software is part of a system. There are interacting parts that when assembled, produce an outcome. Hopefully a desired outcome. In the case of software the interacting parts are more than just the parts. Software has emergent properties. A Type 4 system, built from Type 1, 2, and 3 systems. With changes in time and uncertainty, modeling these systems requires stochastic processes. These processes depend on estimating behaviors as a starting point.

The understanding that software development is an uncertain process (stochastic) is well known, starting in the 1980's [1] with COCOMO. Later models, like *Cone of Uncertainty* made it clear that these uncertainties, themselves, evolve with time. The current predictive models based on stochastic processes include Monte Carlo Simulation of networks of activities, Real Options, and Bayesian Networks. Each is directly applicable to modeling software development projects.

[1] *Software Engineering Economics,* Barry Boehm, Prentice-Hall, 1981.

## Recent Comments