The Law of Conservation of Complexity

“Complexity can neither be created nor destroyed. It can only be transformed.”

I realize that this is not quite a true to form version of the Law of Conservation of Mass. I did not take any physics in school, so I am making this up as I go along, not really trying to adhere to a set of laws, but rather to find a catchy title that people could remember.

A comment by John Kangaraj led me down this line of thought.

“Great post, and I fully agree. The problem (as I see it!) however is this: Cost savings can be obtained by increasing efficiency (i.e. do more with less) and efficiency can be achieved by automation. What better tool than IT to help automation? So as organizations move to automate, they simplify users' tasks and shift this complexity to IT. As a result, IT is saddled with developing, implementing and maintaining systems of ever increasing complexity and inter-connectivity, handled by people that don't understand everything nor have a clue how it all fits together... (i.e. even if they want to, there is no sheet of paper large enough to draw all the elements of the big picture). Unless we have a paradigm shift (I hate that word, but have to use it!), this mess is going to get worse. “

When systems are designed and developed, there is a tremendous opportunity to make the system less complex than the one that it is replacing. This is done by applying knowledge, essentially transforming that knowledge into anti-complexity (simplicity). Unfortunately, as John points out, many organizations and teams lack knowledge, so complexity is added by the transformation, if you will, of anti-knowledge (ignorance). When dealing with a complex system, especially one that is actually and needfully complex, adding knowledge will enable you to perceive the system as less complex. The complexity has been transformed, this time into knowledge.

What can we do?

1. Learn more about the systems we work with and DOCUMENT them. Sharing knowledge is the most efficient way to decrease the perceived complexity of a system. This is especially critical in the areas of system/part interaction. Some years ago, I did a great deal of research into UNDO, a system I initially considered to be very complex. I found that as I acquired knowledge about the system, UNDO become less complex. I had not actually changed the system, I simply understood it better.

2. Look for ways to make the system less complex through the application of knowledge. Ask “Why?” and “Is this essential?”. This will help you identify and remove needless complexity. As Mogens Norgaard points out, the more complex a system, the higher the chance of a normal accident or, as we call them in the IT world, crashes and bugs.

3. Understand there is not a direct relationship between lines of code and complexity. Some of the most complex code I have ever seen (and written) is some of the smallest. Creating and referencing a view in an Oracle system may appear to decrease the complexity, but it actually increases it as it masks the actual operations that are being performed. Using the actual base objects in the application code will make the system less complex, even if it means more lines of code.