Balancing Order and Chaos in Software

The most effective software balances order (stability) with chaos (extensibility). This is not unlike other types of systems, however, in software the consequences seem to manifest themselves much more rapidly. This is because the cost of iteration and change in software systems is much lower, in both effort and time, than physical systems. You don't need to expend time and energy getting to your previous state in software - it's already there. This means that the benefits, and costs, of chaos can be realized very quickly.

The Benefits of Chaos

Norse Analogy

In Norse legend, Loki acts as an agent of "mischief." The "trickster" as he is called is the archetypical agent of chaos. Many may be familiar with the general figure of Loki but let me hammer home a lesson from a particular Norse myth to illustrate the potential of chaos. The story goes something like this...

Thor is jarred awake one morning to his wife Sif weeping uncontrollably due to all her hair having been shaved off in her sleep. Sif was known for having the most beautiful long, blonde hair, but now she was completely bald. Yikes!

Thor wastes no time in snatching up Loki, and by all accounts that would have been the end for the trickster if Odin had not intervened. Odin insisted on evidence before a sentence. Unfortunately for Loki, some of Sif's hair was on his clothes. Once again, however, Odin forbid Thor from eliminating the chaos that was Loki. He instead set Loki out on a quest to make it up to Sif and earn forgiveness.

Loki journeyed to the realm of the Dwarves and came back, not only with new "actual golden" hair for Sif, but several other gifts for the gods, including what would become Thor's most prized possession, the hammer "Mjolnir."

Many of the early Norse myths reflect this trend with Loki (the agent of chaos). Loki's "tricks" rebuild the walls of Asgard, birth Odin's horse Sleipnir, and often save the day (though often this is him undoing his own mischief or "fixing his own bugs").

How it connects

So, how does this relate to software, or other systems? As with Sif's sudden baldness, change is often offensive or even horrifying. Often rightly so, but this chaos can often elicit responses which result in drastic improvements. Chaos, in the form of bugs, new feature requests, etc., can improve software systems in the same way Thor was enhanced by Mjolnir.

In the story, Thor's reaction was one of pure order - he sought to destroy the source of chaos. Odin on the other hand was more balanced. Had Thor gotten his way, Sif would have had to wait much longer to get her hair back, not to mention he would have never possessed his precious hammer.

Most software goes through phases of iteration. If these phases, or challenges, are approached with a balance of stability and extensibility, the engineers maintaining the software will be possessed with the power to fulfill requests quickly and reliably, in ways they could not before.

If software engineers approach this change as Thor, it's likely we'll either be out of a job, or the organization's we're apart of will suffer greatly from the stagnation caused by resisting reasonable changes. When we take a balanced approach, as with Odin, we earn the trust and respect of our stakeholders, and increase the potency and lifetime of our software.

The Costs of Chaos

Norse Analogy

Despite early Norse myths perhaps preferencing the benefits of Loki's mischief, the further chronologically you go the more disastrous the chaos spawned by Loki's behavior becomes. Culminating in the death of the most beloved god, Balder, and the prophecy that he would eventually lead an army of giants, demons, and other fiends to destroy Asgard and most everything else.

At some point, Odin's defense of Loki goes a little too far. It goes beyond the rational and is driven primarily out of love or perhaps habit. You might say Thor too is declawed by his father's implicit defense of Loki. Though his instincts may not change, Thor's agency to deal with Loki's chaos is removed, since he does not want to disobey the "All father," which would obviously be a chaotic and disorderly act itself.

How it connects

Just as software engineers can become too accustomed to the order they've constructed, and offer too much resistance to change, so too can they become accustomed to chaotic or unreasonable change, resulting in ever increasingly chaotic systems being built.

Whereas overly orderly systems tend to fade out slowly as they're replaced by fundamentally newer ones offering features often resisted by the maintainers of the "orderly" system, chaotic systems die quite a bit differently.

A chaotic system will work less and less often over time. Obviously "work" is very subjective, and even more so, in a chaotic system where often there's no rhyme or reason to whether the system is, in fact, "working" without lots of historical, often forgotten, context. Often the system itself may begin to rely on its own chaos, and have irrational exceptions baked in that can become implicitly, if not explicitly, relied on.

Consider scenarios like:

• Handling an uncaught exception results in a new bug being reported

• Fixing inconsistent application of business rules results in "undesired" behavior for some group of stakeholders

• Incorrect reporting, logging, etc. becomes part of the business's baseline expectations and fixing it forces a disruptive reset in judging the software or overall system in terms of its performance or success.

Chaotic systems eventually elicit demands from maintainers, and sometimes stakeholders directly, that they be replaced, rewritten, etc.

Unfortunately, these are some of the most difficult to interpret and therefore, most difficult to replace systems.

Pros and Cons of Order

I won't spend as much time here, since we would largely just be highlighting the opposites discussed of chaos, however, it's worth explicitly stating some ups and downs of order, specifically extreme order.

First and foremost, the principal benefits of order are stability and reliability across time. An orderly system, particularly the sort that sacrifices the benefits of chaos, does exactly what it was designed to do. Such a system's intents and design are much more easily articulated as it generally lacks the quantity of exceptions, which is required in the extreme since any exception which threatens stability must not be tolerated - only well understood exceptions can even be discussed.

For critical systems, those which hold life, limb, or disgustingly large sums of capital in the balance with the execution of their exacting specifications, it's easy to see why engineers might want, and perhaps should, err heavily on the side of order as opposed to embracing a more balanced or chaotic approach.

On the other side of the equation, we can imagine our orderly steam roller plowing through the fields of a changing environment unconcerned that its processes are no longer relevant, that the field no longer contains the resources it once did, and that it may actually be stomping out the seedlings we are now searching for. It doesn't do what it does for the empirical benefit - no, that's too fuzzy and subjective. It does what it does because it is or was "correct." This is obviously a massive problem for most "enterprise" software.

In a perfect world, where explicit perfection had been attained, an orderly system could also be built to perfection and never changed. Once perfect, no change could be objectively superior. Alas, we do not, and cannot ever, attain true perfection. Therefore, all systems must submit to their changing environment, including subjective, or highly abstract, requirements to avoid becoming obsolete.

Exceptions

At this stage I think it is appropriate to point out that when we discuss "systems" we are explicitly not discussing something so simple as an equation or simple function of logic.

Some problems are simple and defined enough such that perfect solutions can be proven for them. Examples would include mathematical concepts which do not change based on environment. Addition, algebra, and trigonometry need not, and must not, change. That isn't to say that a mathematical concept cannot be replaced, however, my point here is that these examples are explicitly not "empirical processes" iterated on for effect, but are, however, "well defined processes" and generally outside of the scope and irrelevant to this discussion.

Within any orderly or chaotic system there can be any given number of these "perfect" solutions to simple and objective problems. Don't think solving these problems are what you're getting paid to do as a software engineer. No, you're there to build, maintain, and iterate on the empirical system attempting to solve, better with each iteration, complex, abstract, and subjective problems.

Conclusion

A good software engineer must recognize the benefits of order and chaos in any given system. At an even higher level, a software architect must work for the business to build a system which will adapt to maximize profitability, efficiency, etc. whilst also locking in as many gains as possible through a balanced strategy which does not neglect the imperative of a requisite degree of stability.

There is no flow chart here, folks. There is no simple trainable process you can follow. No soundbite or buzzword that can make you a master of this balance. It's a matter of developing ever increasingly effective judgement in as broad a manner as possible and then, crucially, having the will to apply that judgement in the domains you have influence in.

Do not become so comfortable in the systems you build that you see successful resistance to change as a victory. Do not build "pets" that you cannot contemplate butchering. Raise cattle and slay them as frequently or infrequently as it benefits your broader objectives. Do not be a yes man who fears disappointing stakeholders. All of these fears should elicit introspection on your own lack of confidence.

Fear nothing. Ride to the cave with a balanced host, slay the dragons, and conquer the hoard!