In this article I would like to show one interesting connection between IT and physics that I’ve stumbled upon, which is to me quite fascinating. It will have some formulas and relate to terms from physics, but I hope you will not shy away because of that.

For all those who don’t exactly know what the fuss about Heisenberg’s uncertainty principle is –  read about it here, or better – enjoy this fantastic video by 3blue1brown.

In short, the principle says that:

The more precisely one property of a system is known,
the less can be known about its conjugate property.

If you’re now scratching your head wondering about what conjugate properties are – again, read here all about it (if you like maths). This mentioned conjugation relation causes that the order of executing the operations becomes important. Okay, I admit, the last sentences sounded dry… operations, ordering, conjugation, uncertainty… TL, DR, See you… but if you haven’t clicked away, then bear with me, please. Things should become strikingly clear now.

Fancy recipe for a disaster …

Let’s imagine two simple operations:

  1. X = putting on ski
  2. P = riding down the slope

Even a kindergarten child can imagine the consequences of doing #1 first, #2 later and compare them to the results of doing #2 first and #1 afterwards instead…

  • ‘put on skis’ and then ‘ride down the slope’ = fun experience
    X * P = Fun,
  • ‘ride down the slope’ and then ‘put on skis’ = interesting thing to imagine, but not necessarily a fun experience
    P * X = Disaster,

As insane as it may seem now, it does bring value to measure the difference between these two:
X*P – P*X = Fun – Disaster, or in short notation [X, P] = Fun – Disaster. By the way – you have just encountered and understood a commutator – here’s a more scientific description.
In human words, the order of executing of these operations makes all the difference between fun and disaster.
Well … that’s not exactly rocket science. Everybody knows that. As useless as it may now seem – we’ve got ourselves either a fancy recipe for a disaster, or:

… a recipe for how to avoid a disaster

It’s just as obvious when one substitutes the operation names in the following manner:
P = altering the code and X = testing what the code does.
After all, if we first code, and then test, we will get the actual information about what the code actually does. If we instead first test, and then code – weeelll, then we only know what our code did before we changed it. That last thing is rather useless.
X*P – P*X = difference between knowing what the code does in the newest and the previous code version.

Still not rocket science, right?
In physicists vocabulary, this is called the non-commutation of variables – read here if you want some ‘technical’ details.
In human digestible terms – if operations commute, there’s no difference in results with regards to order of execution, if they do not –  the order of executing them is important.

But what about the uncertainty?

The Heisenberg’s principle

mentions uncertainty. But wait. Uncertainty about what?
Those of you who are familiar with it, already know that it just says that there is a limited amount of knowledge one can have about a system under investigation. The more one knows about one conjugate property of the system, the less can be known about the other. All that because of the limitation: how one can interact with the system. As one joke nicely frames it:

Policeman: Are you aware that you were speeding at 150km/h?
Prof. Heisenberg: Well great. Now I have no clue where I am.

How does that translate into the IT world?

Let’s consider the following fact: both coding and performing tests on that specific code cannot happen simultaneously. One must be executed after the other. Both however take place in the same project during the same time frame.

The more time is taken for coding, the less time remains for executing tests. = The more we know where the project went, the less we may know where it actually is.

It is one of the typical failures during sprints – to have insufficient time left for testing of the implemented features. How can testing (position measurements) influence coding plans (momentum measurements)? Imagine this type of situation, and I guess all will be very clear: A day before the sprint ends a tester informs the Product Owner that a blocker bug has been found in this sprint’s batch of features… worst case chaos ensues, next sprint scope is affected and … and … and …

But for now let’s just note that:

The outcome of a test (position measurement) may influence the code development plans (momentum measurements).

As simple as it may sound now – there must be balance between coding and measuring what the code really does. Otherwise one risks misleading the project, or if you like the previous analogy – riding down the slope before one put the skis on.

The more observant ones, who are now asking themselves – what about this fancy right side of the inequality – I hope to explain it in upcoming articles 😉

Leave a Reply

Your email address will not be published. Required fields are marked *