Anna Karenina Principle in Software Engineering

Image: A shot from the classic adaptation of the novel “Anna Karenina” Mosfilm. 1967

Recently, I read again Lev Tolstoy’s great novel Anna Karenina.
The first time I read it in school years, as the teacher of literature demanded from us. But to understand such books, they should be read in adulthood, having accumulated enough of personal life experience and understanding of human characters.
From chapter to chapter, Leo Tolstoy describes what is happening, as if observing them through the eyes of one or another participant. And the actions of some of the heroes of the novel, which previously were perceived by frivolous antics or manifestations of their evil will, considered from another perspective, seem deeply logical and even the only possible.
And after reading the novel there is an impression that it could not be otherwise. A light flirtation between a married woman and a young officer turns into passionate love, then into a moral breakdown between the lovers and, in the finale, the heroine’s suicide under the wheels of the train.

And every link in this terrible chain of events at the time of reading is understandable and logical.
After reading the novel, everyone can decide for themselves what this mysterious, the very first sentence of the novel means:

Image: Leo Tolstoy. Source: Wikipedia

„All happy families are alike, each unhappy family is unhappy in its own way.“

One possible explanation is that Leo Tolstoy in this sentence formulated a much more general philosophical principle that manifests itself in medicine, sociology, biology, global geophysical phenomena and, in my opinion, also in Software Engineering.

What does Anna Karenina’s Principle mean?

Interpretations of this principle are devoted to many scientific publications and even the article in Wikipedia.

What does this principle mean? Very complex chemical, physical, biological, psychological, social and other systems can exist long and successfully only if their parts are well suited to each other and to the external environment. If we were able to describe such systems with a certain number of parameters, we would notice that for each class of systems there are very few “successful” combinations of these parameters.

Note: In order to give our parametrized models a greater reality, we should not speak about separate parameter values, but about equivalence classes of parameters. But this does not change the essence. 

Paradoxically, the more complex the class of systems, the less “successful” combinations.

Coffee makers of different manufacturers differ from each other in the technical solutions and even in appearance more than cars, cars more than passenger planes.

The principle of Anna Karenina and the domestication of animals or the limitation and secondary nature of the selection parameters

British scientist Francis Galton, who lived simultaneously with Tolstoy, formulated a principle similar to Anna Karenina’s principle, considering the domestication of animals:

Image: Frances Galton. Source: Wikipedia

“It would appear that every wild animal has had its chance of being domesticated, that [a] few . . . were domesticated long ago, but that the large remainder, who failed sometimes in only one small particular, are destined to perpetual wildness.”

Further interesting discussions on how this principle worked out can be found in an entertaining book Jared Diamond “Guns, Germs and Steel”

Глава 9. Chapter 9. “Zebras, unhappy marriages and Anna Karenina principle” of this book begins with such a phrase :

Domesticable animals are all alike, every undomesticable animal is undomesticable in its own way.
If you think you’ve already read something like that before, you’re right. Just make a few changes, and you have the famous first sentence of Tolstoy’s great novel Anna Karenina: “Happy families are all alike; every unhappy family is unhappy in its own way.” By that sentence, Tolstoy meant that, in order to be happy, a marriage must succeed in many different respects: sexual attraction, agreement about money, child discipline, religion, in-laws, and other vital issues. Failure in any one of those essential respects can doom a marriage even if it has all the other ingredients needed for happiness.

Further, the author calls factors that prevented, despite numerous and continuing attempts to domesticate wild animals. They are few: diet, growth rate, reproduction problems in captivity, “savagery” of character, propensity to panic, social structure.

It is interesting to note the fact that all the factors listed by the author are “secondary”. For example, mankind uses as meat-supplier not rhinoceroses (3 tons of meat) but much smaller animals – cows, pigs and sheep.

In other words, if we had programmed an animal selection algorithm for domestication, we would have to use as parameters not the primary attributes of this kind of animal (weight, height, life span, etc.), but secondary ones, calculated using special functions. And already on them we would impose very strict restrictions.
If you are interested, then read the book.
But the author explains the principle in a particular subject area. Is there a wider interpretation?

The principle of the fragility of good

A brilliant mathematician Vladimir Arnold tried to look at the problem from a broader and at the same time purely mathematical point of view in his book The Theory of Catastrophes

There he describes the «The principle of the fragility of good».
He wrote:

Image: Arnold, Vladimir Igorevich. Source: Wikipedia

… for a system belonging to a particular part of the stability boundary, with a small change in the parameters it is more likely to hit the instability region than to the stability region. This is a manifestation of the general principle that everything good (for example, stability) is more fragile than bad. Apparently, all good objects satisfy several requirements simultaneously, while an object that has at least one of a number of shortcomings is considered bad.

In the context under consideration, Vladimir Arnold was probably right. But in a broader context, one can see that in fact, he speaks of fragility, or rather of a rarity of stability, and not “goodness.”

Not everything that is unstable is bad. Not everything that is stable is well.

Who ever passed a puddle or a ditch on a beam understans me. It is unstable to move around the beam. But it is better than to fall down and take a stable position in the ditch 🙂

On the other hand, any movement is rather an imbalance. Trees and flowers are good as long as they are alive and growing, and withered – usually not.

And at the same time, about a tree that grows hundreds of years, intuitively we want to say that it stably (steadily) grows.

Let’s sum up the summary: Stability and goodness – the indicators are more independent of each other and depend on what we measure or simulate. It should be added that stability is more of an objective, measurable parameter. What is good and what is bad is the subjective decision of the observer.

Anna Karenina Principle and attractors

Reflecting on dynamic instability, we almost inevitably come to the concept of chaos.

The theory of chaos is a relatively young science. About its formation and the first steps, the book”Chaos: Making a New Science” of James Gleick. One of the most fascinating subjects in this book is the discovery of such a phenomenon as attractors.

The attractor is a compact subset of the phase space of a dynamical system, all trajectories from some neighborhood of it tend to it for a time tending to infinity. An attractor can be an attracting fixed point (for example, in the problem of a pendulum with friction about air), a periodic trajectory (for example, self-exciting oscillations in a circuit with positive feedback), or some bounded region with unstable trajectories inside (as in a strange attractor).

Below is one of the variants of the Lorenz Attractor.

Image: Lorenz attractor. Source: Newcastle Engineering Design Centre – Newcastle University

What does attractors have to do with the Anna Karenina Principle?

I think from the philosophical point of view attractors represent in the world of chaos “the happy families” while the other points of the phase space are “unhappy families, unhappy in their own way.”

There are too few trump cards in the desk …

You’ve probably heard about the long debate of Einstein and Bohr about the fundamental foundations of quantum physics. The discussion was centered around the question of which model must describe the trajectory of a single elementary particle: deterministic or probabilistic. Two great physicists abstracted the essence of the dispute to a half-joking question: Does God play in the dice, controlling the movement of the particles of our world?

Over the past century, the description of the world has incredibly multiplied and become more complex. Continuing the line of Einstein and Bohr in relation to the current situation, we can say that to manage the world, God needs tools more complex than a dice. For example – a deck of cards 😉

Then, taking into account Anna Karenina’s Principle, one can say that the deck of cards God chooses to manage natural and social phenomena is usually not very good. There are too few trumps in them …

Well, the phenomena themselves are divided into stable and unstable. At the same time, “very” unstable over time often “roll down” onto attractors.

How we divide them into good and bad depends on us. But it seems that the current world is more unstable than stable. And it conains more bad things than good things.

In other words, the world looks like it is on my picture below.

The Anna Karenina Principle in Software Engineering

All these theses can and seems to be true, perhaps one of the readers has already thought to himself. But where are the promised in title Software Engineering? Does Anna Karenina’s Principle work in these areas of human activity?

I’m sure it works. If only because this general principle simply must act in this particular subject area. At least for those software-hardware and purely software systems, which are quite complex and dynamic.

The Anna Karenina Syndrome

If the Anna Karenina Principle (AKP) in Software Engineering is present, how can it be noticed?
First, if your system is stable and allows you to expand and configure it painlessly, you do not need to worry much. Your system is in a stable-good part (see the picture above).

If your system is not very good or not at all good, but is stable and does its job (located in an stable, bad part of the world), you should think carefully about whether it is worth risking and changing something radically.

The AKP begins to show its negative side, if attempts to correct specific mistakes only worsen the situation. Errors are indeed corrected, patches are installed, but new, more tricky mistakes emerge from nowhere. In such cases, we can talk about the Anna Karenina Syndrome (AKS).

Recall that the syndrome is a complex of organically related symptoms (symptoms), united by a single mechanism of emergence and development.

Depending on the size of the system, the AKS shows itself differently. But most manifestations boil down to certain “scandals”.

At the bottom, I tried to list (far from complete) the characteristic symptoms belonging to the AKS, depending on the size of the system.

In the enterprise brawl the people

In large enterprise systems, the software and hardware problems of the IT components quickly transform into psychological wars between managers or whole divisions. If we try to filter out subjective psychological aspects, then objectively recorded phenomena often remain:

  • We have to do more and more workarounds.
  • In workflows suddenly emerge phantom-instances of processes.
  • Instances of workflow processes split or do not end correctly and start wandering through workflows. Due to their incomprehensibility, the staff voluntarily or unwittingly pushes them further and further.
  • Automation of workflows is replaced by manual operations.
  • Data is corrected using scripts run at night.
  • The running system has to be stopped and restarted more often.

In large client-server systems brawl the components

At the level of individual systems with the client-server architecture, the AKS is often manifested thus:

  • “Zombies” unexpectedly appear in Data Bases. (Under “zombi” I mean the incomplete entries with incorrect external links, which seem to be impossible to create by regular scripts and processing programs. In German IT jargon they are called Leichen – corpses).
  • Situations, when yur system “crawls on all fours” are often. Sometimes you system unexpected just “falls down.”
  • “Special areas” appear. It can be groups of user masks that only few users dare to use or access to which without comprehensible reasons is restricted or closed.
  • Strange errors occur when converting data, for example, when sending data to partner systems.

In small systems brawl modules and classes

At the level of small systems (for example – Desktop-Applications), the AKS manifests itself in the following::

  • Users complain about phenomena that can not be reproduced.
  • Linear extensions, such as a new business function, leads to errors or failures in previously working modules.
  • Secondary changes (such as changing colors in the GUI) result in errors or failures in the main functionality.
  • Idempotency of operations is lost (for example, calculations that in theory should not change the state of the system, repeated several times give different results.

Can we change the quadrant?

Is it possible for our system from the lower left quadrant (see figure above) to change this quadrant to another?

I think not always. Sometimes the system is easier to replace than to try to cure. Fortunately the average lifetime of modern IT systems is short – about 10 years. (This statement is the result of my observations, not official statistics.) It is amazing that approximately the same amount of time is required to completely update the cells of our body.)
Where do our problems come from? As a rule, most problems arise when the individual components are incorrectly selected or programmed or the elements of the basic frameworks are used not correctly.
For example, in my professional career, I observed the development of several projects that were based on supposedly brilliant algorithms. These algorithms were implemented first in obsolete programming languages. The importance of these initial kernels seemed huge at the beginning of the project. Therefore, customers insisted that these kernels must remain in the system.

The architecture and even the user interface of the systems were developed to usung of these cores. In the end, the cost of wrappers and interfaces to cores was tens of times higher than the cost of realizing the kernels themselves (if they were implemented anew). The wrappers and interfaces were shaky and “generates” many problems.

What can we do

The enterprise can often afford a radical solution – the replacement of one component by another. Often this is really the only acceptable, albeit very painful solution.

If the system is unique, too important for your business, or the migration and cost of licenses for the new system are too large, you should try to cope with the AKS in place. Then a question arises:

What’s wrong with us?

This is the key question. Why does a competing or similar system not fall in this place, and yours falls?
Often, because there are several components in your system those do not correspond to proven best practicies.

If you find them and systematically fix them, replace them, properly configure them – then maybe your system will become less unique, exotic, esoteric, mysterious, but it will stop torturing you. But I repeat – the task is not to correct the accumulated errors, but to perform a system analysis and, as a result, to make refactoring or reengineering of your system.

But then …- it will become more like other successful systems. Just like “…All happy families are alike.”

In the end, I will allow myself to propose a specialized formulation of the Anna Karenina Principle in relation to IT systems and programming:

All successful systems of the same domain are similar to each other, each problematic system is problematic in its own way.
Problems arise very often because using of “exotic” solutions and components instead of best practices. “Exotic” solutions and components “penetrate” into the system because of low skills or unwarranted enthusiasm of developers, managers or customers.

If the business and technical indicators of the system are bad, correcting some errors in it leads to the emergence of new ones – it is most likely manifestations of the Anna Karenina Syndrome. As a rule, in this case, a radical refactoring of the system or replacement of its some parts or the whole system is required.

The first version of this article I discussed with some of my friends who have extensive experience in the development or operation of IT systems. Some of their comments and suggestions moved me to rewrite and expand the article. I want to thank Igor Bass, Oleg Trufanov and Sergei Shishkin for really valuable comments.