CTO Articles
Published in IT World
E-Business in the Enterprise – May 31, 2005
Complexity, chemistry, commuting and computing
By Sean Mc Grath
The complexity of a business process, Tesler tells us[1], 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[2].
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[3].
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'[4]. 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[5]. 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.
Take Python for example. In Python, a periodic table of the operators would be short and rectangular in shape. In Python, there are a core set of complexity management devices that are used over and over again, in a variety of contexts. Is this the right way to do it? Opinions differ.
A final example, do you remember the RISC versus CISC wars that are now a distant memory? Is it better to have a small number of instructions with which to manage complexity but make them really, really fast or is it better to have a wide range of instructions at the expense of individual instructions being a bit slower? Which is the right way to do it? Opinions differ.
The important point here is that inherent complexity is inherent complexity. It cannot be destroyed. It can only be moved around. The opinions you hold about any of these matters is an indication of where you feel inherent complexity is best addressed. Your personal view is dependent on your own thresholds for complexity and where these thresholds lie.
Which brings us to another law: Tog's Law of Commuting[6]. Yes, you read that right. Commuting, not computing. Tog's Law of Commuting states: "The time of a commute is fixed. Only the distance is variable."
As humans, we have thresholds for things such as risk (physical or financial), stress and so on. Tog is talking about commuting as one of those things we have a threshold for. The distance to work is not the important thing. The important thing is the time it takes. If commuting time is halved, people by and large will feel comfortable moving further away until the upper limit of their threshold is reached again.
This threshold principle applies to software development too. We all have thresholds for complexity. Once we hit these we feel uncomfortable. Ideally, we find a way of reducing the total amount of complexity back into our comfort zone. If this cannot be done because the complexity is inherent to the problem, then we need to move it. Maybe we care where it is moved to, maybe we don't. The important thing for our stress levels is that it be moved.
A lot of the jostling in the teams building software systems can be understood in terms of the trading of differing complexity thresholds between team members and differing opinions about where inherent complexity is best handled.
Given that diversity in people is an inherent characteristic of being human and given that inherent complexity cannot be destroyed but can only be moved endlessly around, I suspect that the programming language wars are here to stay. They form part of our rich ecosystem of complexity management - both social and technical - without which we would not feel comfortable.
[1] www.google.com /search?hl=en&c2coff=1&q =Larry+Tesler+law+of +Conservation+of +Complexity &spell=1
[2] seanmcgrath.blogspot.com /2003_07_20_seanmcgrath_archive.html #105923521456343257
[3] terri.zone12.com/doc/other/security-hf/node30.html
[4] www.google.com/search?q=programming+language+wars
[5] www.ozonehouse.com/mark/blog/code/PeriodicTable.html
[6] www.asktog.com/columns/011complexity.html