The complexity of a business process, Tesler tells us, is like energy, it cannot be created or destroyed, it can only be moved around from one place to another.

To be more accurate, Tesler's law says that for any process, there is a base level of complexity that is inherent to that process. Once you hit that base, you cannot simplify the process any more. You can only move the inherent complexity from one place to another.

Tesler's law is a nice illustration of McGrath's Law which states: most people, sometime or other, will think up what they think is a new universal law only to find that somebody else got there before them.

As you will know if you followed the last link, I like Tesler's law so much that I independently 'invented' it long after the original. I try to keep Tesler's law in mind as I go about my daily business. For example, in systems analysis, the ability to distinguish the inherent complexity of a business process from its surface complexity is a key skill. The ability to know, as a software developer, that you have reached the point where you are just moving inherent algorithmic complexity around rather than reducing it, is a key skill. In software team management, the ability to spot when your team is 'feather dusting' inherent complexity rather than vacuuming is a key skill. (Think of feather dusting your living room. You may think you are improving matters but all you are really doing is making the dust airborne. It will simply settle somewhere else when you stop.)

The analogy between conservation of complexity and conservation of energy breaks down of course. (I'm sure there is a rule named after someone that captures the inevitable breakdown of analogies.) For example, in the world of energy physics, moving energy around is something that is done logically and fairly. Nature does not care where the stuff gets moved to as long as two conditions hold. First, all the energy must still be there when it arrives at its destination. Second, the laws of physics must be observed during the transition.

Contrast this with business process complexity. Given that one person's complexity is another person's simplicity, we are straight away into a very different ballgame. Complexity in this game is relative to a point of view. That is the first major difference. The second major difference is that in the business process complexity game, things are not logical or fair necessarily. Sometimes, people know they are simply moving complexity around rather than reducing it, but they just keep on moving it anyway. Sometimes, people do not care whether the complexity is being reduced or simply moved, as long as the issue has been successfully turned into someone else's problem.

These are some of the obvious, timeless Dilbertian facets of the human approach to complexity management. In software engineering, we have these in abundance but we also have a different kind of complexity management. A kind which

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine