How to Stew Fragility into Stability

We all are familiar with the following recipe which is a linear process, aren’t we?

1. Do this.
2. Then that.
3. And repeat until …
4. etc.

It has an expected output and is repeatable.

While creating a recipe is non-linear and therefore more difficult as shown in my previous blog,“How to bake an agile cake”:

But once a recipe is found, then it is relatively easy to repeat – too bad it often can’t be mirrored to the world of IT.

I often see IT-processes/IT-solutions/standard deliveries/automation that require a lot of fiddling and tinkering before the output resembles anything desirable. I asked myself “why” and “what happened” many times, to understand the reason behind it.

The answer is “The amount of uncontrolled change”:

Imagine the flour gets an update from “flour 1.0 (Wheat)” to “flour 1.2 (Soja)”. It might make your recipe utterly invalid unless you add more flour and water, which could influence the temperature and time in the oven.

Now imagine also the oven changes:

• The oven got “upgraded” and warms now 15°C less (to compensate the last error of warming 10°C too much).
• A supplier of the oven changed the interface, so now shows the temperature in Fahrenheit instead of Celsius.
• The government has implemented a law, which requires one of the ingredients to get maximum 185°C

What temperature should the oven be set to for the cake to become a success?

• 338°F?
• 347°F?
• 356°F?
• 365°F?

You might think the answer is 356°F, but with the flour upgrade, we wouldn’t know. You would need to redesign and retest the complete recipe:

Image credits: Bartek Rohard Warszawski

Enough change will break any IT-process, standard IT-delivery, IT-solution, and even automation. You can either lower the amount of change or try to control it.

This is the main difference between the science of physics and economics. The universe changes slowly and therefore predictions in physics remain reliable, while the markets changes quickly and therefore predictions in economics become unreliable.

Controlling change

A product can be influenced by

• Change requests for the product.
• Changes in the tools to build the product.
• Changes in the components of the product.
• Changes in the media the product will be used in.

But each tool, component, and media is a product in itself and therefore is influenced by its own tools, components, and change requests.

The influences on your product can be illustrated by a network-diagram:

Image credits: Bartek Rohard Warszawski

Local changes are relatively easy to deal with.
Second-degree changes in the tools, components, and media, are difficult to deal with.
N-degree (third, forth, etc.) changes in components behind components or media behind media seem impossible to deal with.

Proactivity might seem futile, but don’t forget that changes can be:

• Stopped, like making a local copy of a component, so it can’t be updated.
• Postponed, if a lot of other changes are happening.
• Tested and fixed, for local and second-degree changes.
• Monitored in production, for third-degree impacts –  we won’t know when they will happen, but we can detect or forecast when they do. A hotfix can either solve the problem or apply a work-around. These changes are rare, but they happen more often than you think. Mostly we don’t sense them since they drown in the amount of changes, which could have been stopped, postponed or tested.

Example of a n-degree change: 11 lines that broke the internet (Read more at sciencealert.com)