Everything devolves through insufficient maintenance – a useful climatic pattern?

Technical debt is a serious issue. It is not yet certain how Wardley maps can be applied to visualize and manage technical debt. It is probably safe to assume someone in the Wardley mapping community will write a seminal article on the topic.

In the meantime, it might be useful to ask if there are sufficient orthodoxies in mapping to help us think about technical debt. In the context of components, Wardley’s set of climatic patterns includes:

Everything evolves through supply and demand competition.

Borrowing somewhat from the second law of thermodynamics, could we introduce a complementary climatic pattern, such as:

Everything devolves through insufficient maintenance.

Is the proposed climatic pattern valid? Does it make sense? Would it help you to think about maintenance and technical debt when mapping?

It would be useful to coalesce around a consensus either way.

Notes

Corrective/Adaptive Maintenance

Vendor upgrades (bug fixes and optimisations) generally eliminate technical debt. However, breaking changes transfer technical debt up the value chain.

Adaptive Maintenance or Redesign

General-purpose technologies (GPTs) often enable various complementary innovations that use the particular technology to make a process even more efficient. However, because GPTs form the centre of a network of complementary technologies, it means that, if the GPT becomes inaccessible for some reason, all the complementary technologies will be negatively impacted.
Helpman, 1998. General Purpose Technologies and Economic Growth.

On this basis, a component can become inaccessible through changes in regulation, obsolescence and/or the availability of (natural) resources. Technical debt is eliminated by replacing or redesigning subcomponents entirely.

References

1. Backward evolution
2. Learning climatic patterns
3. Climatic patterns
4. Obsolescence Climatic Pattern. Nov 7, 2019
5. X : How do you show technical debt on a map? Aug 23, 2019
6. X : How to deal with technical debt? Dec 1, 2018
7. Wardley Mapping Technical Debt of a System. Nov 30, 2018

I’ve framed/visualized the obsolescence pattern (Red Queen hypothesis) in two additional ways:

One additional way to visualize this is a z axis (height) with a constant slope up towards commodity. Basically, far right x axis being highest, far left being lowest. Evokes our physical intuition that we need to apply constant force to keep something from rolling downhill.

Another way to visualize this is to concieve the canvas underneath the the x-axis to be a treadmill that moves from right to left, but this may be departing too much from what makes a map a map.

Obsolescence rate is different for different activities, so it is difficult to represent this force consistently across different types of activities on a map.

Re-reading Learning climatic patterns, it seems that what we may be doing here is naming what Simon defined by absence. Simon talked about Red Queen hypothesis mostly in terms of survivors, which makes sense as that’s the intent of the reader.

Chaos Engineering framing is also interesting to consider here. The main idea being that in order to prepare for an unpredictable unstable operating environment, we deliberately make our environment less predictable and more unstable to force adaptation. In this framing, the planned obsolescence of version upgrades and long-term support lifecycles looks like a way of purposefully obsoleting in order to force adaptation.

What is missing from Simon’s diagrams (attached below [1]) is that after the market is penetrated in nearly 100%, when a new solution emerges, the penetration of the older solution becomes smaller.

Less people knows how to use a component and uncertainty actually grows. In the extreme case, we get a few specialists, or even a system that runs but nobody knows why and how.

On the activity level, Evolution moves forward, but for a particular instance, it moves backward. JavaScript replacing Java moves programming languages forward in Evolution, albeit just a little bit, but at the same time Java becomes less popular, grows slower, and less people knows how to use it.
[1]

image957×744 30.6 KB

@chris.daniel a quick question. Does your observation apply to all types of components, even custom-built?

Good one!

I had product & utility in mind, I have no idea how this process may look like in a custom-built space that never has a widespread knowledge. I can imagine that a failed/abandoned custom-built component can be accounted as being an experiment. But I have never observed that yet.

I am not sure that maintenance alone will address the tech debt.
I am dealing a lot with tech debt in banks and it is much more complex than that. Tech debt is generally an operational debt and lack of engineering upskill to be honest.

I like the idea of a new doctrine actually.
Much of the tech debt is in fact a result of cost accounting with a focus on Capex over Opex and associating IT investments to Assets, without a consideration that they are also a liability. Once we can hammer this into Accountants / CFOs head, we can hope to implement better dynamics in the world of Digital.

So maybe something like :
Every asset becomes a liability unless it evolves

(some start as a liability when test automation is not built in actually!)

@pguenet can every component in a value chain be considered an asset?

Would the proposed climatic pattern make more sense if the word maintenance was replaced by energy?

Everything devolves through insufficient maintenance.

My understanding of technical debt is based on the following quote:

Becker and colleagues (2015) described technical debt as “the longevity of information, systems, and infrastructure and their adequate evolution with changing surrounding conditions. It includes maintenance, innovation, obsolescence, data integrity, etc.”
– Kruchten, Nord, Ozkaya. Managing Technical Debt, 2019

@john.grant

can every component in a value chain be considered an asset?

No I don’t think so - some of the value chain can actually be activities, etc.
So, not always an asset indeed.

It might be interesting to consider patterns around Opex and Capex elements and maybe colour code them. An accountant view would be to minimize Opex to reduce running costs and favour investments.
This often plays against using commodities like the Cloud, because it is Opex. The issues with this is that people do not see the on-going cost of maintenance of Capex systems, the obsolescence needing redesign instead of evolution, the cost of delay and opportunity, the duplication, etc.
This surely fits in the patterns of inertia.

Everything devolves through insufficient energy.

may be
Devolve term might not be best.

Technical debt is often the result of operational debt. If you only address the technology, it will come back.

Very interesting post, thanks! Only think I have to contribute the discussion is that IIRC in Toyota Kata form the above statement would recite Everything devolves through insufficient improvement.

This would match my experience where systems under (just) maintenance are actually still degrading, only more slowly. Wdyt?

Hi there,

I am using Wardley Maps as a tool for strategic software architecture management and I’d like to share some thoughts on this with you.

In 1994 David Parnas introduced the concept of “software aging” where “Lack of Movement” is identified as a major cause for aging. Software aging is pretty much what happens when the Red Queen kicks in: Everything around us is moving, and a once perfectly fine piece of software that was left untouched may not even be executable anymore. Though, even when the code is left unchanged, everything else surrounding it evolved. The system landscape is not the same as before, infrastructure changed, etc. so the software is incompatible with todays runtime environment.

The “Lack of Movement” that Parnas described means architectural erosion, which translates to de-evolution of a component on the map.

I was thinking about that for quite some time and asked myself if this means that there has to be an own type of evolution for architectural components so that different concepts (like de-evolution) may be applied. In the meantime, I no longer consider this necessary, as the reason for a changing environment is still competition in the market. The software component itself may be completely independent from market pressure, but vendors, suppliers and framework providers are not.

Long story short:

• A paper written in 1994 identified “Lack of Movement” as a major threat to software quality
• The concept is closeley related to the “Red Queen Hypothesis”, something we can map very well today
• Placing software components on a map forces us to think about their movement relative to the anchor
• Since everything else may be moving pretty fast (typical for IT/software development?) some components will fall behind (architectural drift/erosion) and thus de-evolve.

I found it very useful to add quality attributes (like maintainability) to the map, either as a Need of the customer or as a component of the type Practice. This is very helpful inmapping the results of qualitative assessments.

Any thoughts on that? I’d love to get some feedback on this.

Thank you for your thoughts @umberto.nicoletti .

In 1976, Swanson identified 3 causes of maintenance activity:

• Corrective maintenance – is undertaken in response to failures.
• Adaptive maintenance – occurs in response to changes in the environment.
• Perfective maintenance – aims to eliminate inefficiencies, improve performance, or maintainability.

Is ‘improvement’ equivalent to perfective maintenance?

@umberto.nicoletti Swanson’s maintenance types also seem to align to, albeit overlap, the stages of evolution on a Wardley map?

Evolution-Maintenance1100×211 38.7 KB

wow, that’s a good question. I’m not sure I can provide an adequate answer.

My understanding of the TK is that unless there’s improvement, chaos and failures will eventually take over any perfectly working system/process. This matches very well my experience in the software industry where any perfectly working software will slowly degrade: a most common example are dependencies that go out of date or disappear entirely and same for build tools.

I would therefore conclude that all 3 of Swanson maintenance type would qualify as “improvement”. Wdyt?