From the Mist

We find it so hard to cope with complexity in IT, that every time an evolving standard, like UML, is becoming too complex, we tend to drop it in favour of something new. The new being, because it is new, simple and understandable. While it lasts …

We see this with the rising popularity of Ruby. Developers are flocking to this new thing as if mesmerized, disillusioned by the complexity of delivering value with the Java frameworks.

Now there are two reasons something can be complex. In fact I propose there are two classes of complexity.

1. Flawed complexity. It is handicapped by nature, and all the add-ons that make it complex are added in a vain and ever more frantic attempt to make it manageable.
2. Living complexity. It is growing in a natural way, and complexity is a derived attribute of its growth, but the essence in the local structures remains simple and effective.

UML is, I would like to propose, simple in its essence, being of the second class. The basis axioms remain easy to understand. Java EE on the other hand (to name a rather random other standard) is not simple, not in its building blocks, and not in the way it has to be used. It belongs to the first class of complexity.

Naturally complex solutions still remain complex, and require mastership in using them. It is counterintuitive in some aspects, one being that it is useless to attempt to understand it in its entire structure. Human beings, especially engineers I am afraid, have this urge to get an overview, to understand the global picture. With any class of complexity this is useless. However the second class of complexity offers help in the essential characteristic of being simple in its local structures. When you zoom in into the complex weave, any place you find yourself in is easy to understand, easy to do things in. When you zoom out, the structure quickly becomes unintelligible. With the first class of complexity zooming in will never offer solace, every local structure is still so intertwined with transitive dependencies that changing any local aspect can break something several degrees of separation apart.

The fact that UML in the essential building blocks is so simple, is as far as I am concerned the reason it should not be thrown away just because the standard as a whole is becoming so complex. The attribute of local simplicity is what we should judge standards with, not the attribute of global complexity.

Solutions we create are complex by nature. This is not something to avoid, but instead something we should deal with. Making a distinction between these two kinds of complexity can help.