May 19, 2005, 2:28 PM — 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 is, um, more complex than these.
I speak of programming languages and in particular what are known as 'programming language wars'. Looking across the rolling hills on which these things spring up and multiply, a rich harvest of complexity management devices can be found in operation.
(A warning before we start for those of you with significant programming language knowledge. I am not going to go any closer than a geostationary orbit above this topic. A proper treatment would require a complete book rather than the tail-end of an article.)
I recently came across Mark Lentczner's inspired diagram - Perl Periodic Table of the Operators. In one page, it says more about how Perl approaches the problem of taming algorithmic complexity that any amount of words can. Simply put, Perl puts a vast array of language features in the hands of algorithm designers to tame complexity. Is this the right way to do it? Opinions differ.
Then there are languages like Java and C#. In these languages, a periodic table of the operations would be very dull because most of the complexity management devices do not live at that level. These exist in the vast associated standard libraries known as the JDK and the CLR respectively. Is this the right way to do it? Opinions differ.
