Samstag, 14. November 2020

The long shadow of innovation, or: Lean digitisation and the car

 Inception of Technology

The inception of technology often runs through the following stages: luxury, wider adoption followed by systemic effects and finally this technology often becomes infrastructure and we become dependent from it. What once was fancy, a luxury eventually became a requirement for our life and for other processes in our society.

These steps can easily be followed with the car as with many other technologies (electricity, elevator, telephone, internet, etc.) Some of the systemic effects are predictable early on, many are not and need to be constantly monitored. A technology becoming infrastructure puts a huge burden on society: infrastructure is hard to change and usually expensive to maintain. This does not mean we should not build infrastructure, but we should be very careful what we add to our existing infrastructure and in which exact implementation. 

The Car

The car is an excellent example of a technology that was very badly steered in its inception, thus inflicted massive damage on societies. Instead of using the benefits of the car cleverly, we made large parts of our society dependent on it, severely damaged the social fabric in cities and villages, harmed the environment and living standards in the process. In some countries the situation is obviously much worse than in others. The US took a specifically bad route. Lee Vinsel et al describe this as

»the great American experiment of suburbanisation.« after the second world war. »They were, in the scope of human history, extremely low-density “towns,” and yet they also required more intense infrastructure: more roads, more sewer and water pipes, more utilities.«, Vinsel, Lee; Russell, Andrew L. The Innovation Delusion

The focus here is: more roads are needed, because everyone became heavily dependent on the car. They continue:

»the initial postwar suburban boom pales in comparison to what happened next. Beginning in the 1960s, white flight and other factors hollowed out the economically productive city centres throughout the country, leaving dead downtowns that were largely devoid of life outside business hours. Infrastructure has rotted in the so-called Rust Belt and in cities around the country where tax bases have evaporated.«

Dependency is unfortunately not linear but usually multiplies and creates webs of dependencies. Housing is dependent on the previous one(s): car, road, then follow electricity supply in the suburbs, food supply, etc. Once multiplied it gets harder and harder to correct these substantial mistakes. 

Parts of Europe did indeed a bit better – specifically cities – but not necessarily because we did more clever planning. Politicians were simply more bound by old city infrastructure and architecture. In plain words: the older and nicer, more social buildings, squares, architecture from the 19th century and before saved us to do the worst mistakes. Nonetheless, some politicians actually used the phrase car friendly city. What an absurd twist of facts: suddenly we have to accommodate technology not the other way round: take care of peoples needs and ask, how technology could help.

Today, many cities recognise that they took a very wrong turn and start to understand the damage this path inflicted on people. In some progressive cities like Amsterdam or Paris politicians try to undo (parts) of these mistakes. But as the car became (»webbed«) infrastructure, this turns out to be very costly and difficult – even in cities that are not as dependent on cars like cities in the US or some Asian countries .  

The bottom line here is this: it is much, much easier to introduce a new technology than to get rid of this technology again – after we became dependent. 

Digitisation on the brink of chaos

Now we stand on a similar junction with digitisation. Digitisation meaning: transforming formerly »analogue«, human driven processes to digital, computer based ones. 

With digitisation – as with many other innovations – we did not learn from past experiences with other technologies and severe mistakes we made there (on a structural, meta-level). We particularly did not understand how costly bad decisions can get over time. Now, thinking before acting is generally good advice. Doing what is technically feasibly, not matter what (and calling it innovation) – not so much.

Until recently, reasonable people who asked for slowing down a bit, to deliberate before jumping onto the next bandwagon where ridiculed. We (and I am saying intentionally »we«, because I am guilty myself) called them names like »Internetausdrucker« (old farts you print out the internet) etc. However, it turns out: slowing down things a bit is actually a bright idea.

Particularly as we start seeing the devastation that the move fast and break things ideology inflicted on our society. I am not going into details here, because these effects are discussed everywhere these days; just some hints: (a)social networks, monopolies we cannot fight any longer because they became more powerful than states, »disruptive« enterprises like Uber that never made a buck, but in the process destroyed hard fought rights of the poorest in a society, surveillance capitalism and many, many more. 

And we have not even seen the worst: long term effects of short term gains (for consulting agencies, »digitisation experts«, monopolies) turn out to be terrible. Why? As Vinsel et al correctly point out: innovation is (the starting point) everyone talks about. What is not talked about is: every technology we introduce into our world has to be maintained. Specifically when it becomes infrastructure as argued in the beginning. Now this is problematic enough, because in the digitisation projects usually only the short term gains and costs are argued for. It is forgotten that long term maintenance can become very expensive. By various reasons: for one, the overall complexity of the IT infrastructure is rising and complexity tends grows much faster than the benefits and faster than our means to keep up with it.

What makes things worse is that the implementation quality of many (read: most) IT systems is abysmal. This low quality of implementation multiplies the effects mentioned before. What we will see is: (1) long term dependence on systems that were introduced with not a lot of foresight in mind where (2) the costs will outnumber all benefits in mid term.

What was supposed to be efficient will turn out as uncontrollable pain in the ass. Or as Nassim Taleb put it astutely: 

»Most modern efficiencies are deferred punishments«

However, to be clear: most of us will be punished if we continue the current path, but a small minority (as we well know in our current economic condition) will collect the majority of the gains. 


I hear you say. No. It is not my point that we should throw all our digital systems out. It is s not to say that we cannot benefit from digitisation. We can, if we do it cleverly. But there is absolutely no time to loose to change the current path. To outline a few concrete aspects to consider for a lean digitisation in the future: 

  1. Digitisation is not a value per se.  It has to be well argued for. Don't do it because it is fashionable or your consulter tells you that you will miss the next disruption if you will not (and all others are doing it too (he tells them the same thing about you)). Were no clear and long term benefits can be reasonable argued, stay analogue, human.
  2. Innovation per se is nothing; Innovation essentially means: we introduced something new. Progress is what counts. Progress requires deep thinking and monitoring of the impacts of innovation. It has to be explicitly on the agenda. We have to ask the difficult questions, not evade them. Questions that ask for qualities not quantities.
  3. As far as software is concerned: Software is rarely isolated. If you develop software for a company, organisation etc., chances are, you will be part of a complex web of dependencies that tend to become infrastructure just by the fact that no one knows any more what is part of a process and what is not. This includes data dependency and process dependency. Hence Datensparsamkeit was only the first important idea. Dependency frugality (as I would call it) has to be the second. Be as independent as conceivable (e.g. never use cloud services of monopolists).
  4. We face deep knowledge loss, because knowledge that is embedded »in humans« and »analogue« processes gets captured in IT systems. Usually people operating these systems loose this knowledge quickly.  If not managed properly you will end up in a decade with a technical system that does something — arguably correctly, but you really don’t know — and no one in your Organisation can tell you any more what this system is doing. Combined with the usual bad engineering: good luck changing, migrating or even retiring this system. 
  5. We have to consider long term costs. In many cases it will turn out that long term costs will by far eat short term benefits.
  6. We face severe, possibly existential security risks in our current low quality but highly connected digital infrastructure.
  7. We most importantly have to consider maintenance of each innovation introduced, avoid innovation where maintenance is unclear (e.g. home automation)

These are just some bits and bobs that should be analysed more systematically and deeply to illustrate what should be done. 

The bottom line is: we can and should learn from past examples like the crude introduction of the car into our lives. What seemed like a good idea at the time turned out to be a terrible mistake. It will cost us dearly in the future to get rid of the car again in many places, survive the environmental and the systemic damages. We could have much more liveable cities, more resilient mobility and – indeed – the car for certain useful cases. We had the choice but did not take it. 

We (still) have the choice with digitisation. We can do it better, we can do lean digitisation, or clever digitisation, however you want to call it, or we can follow the current path. This will cost us a fortune in a few decades.


Addition on 29.11.2020 

In the last days an Amazon AWS datacentre had problems and a number of cloud services did not work properly any longer. The consequence? A large number of (US) web services did not work any more or not reliably because they were all dependent on this cloud service.

But not only web-services were affected: our modern digitisation is so driven by terrible architectural decisions (and demands from surveillance capitalists) that also door bells, thermostats and vacuums (among other devices) stoped working.

Incidentally, this is exactly the same point that Nassim Taleb is regularly making: volatility is not the problem. There is no systemic risk. The problem is idiotic concentration of services for pseudo-efficiency which makes the whole system fragile. We are transforming the internet – which was inherently resilient – into a fragil behemoth that risks our global digital infrastructure.

Addition on 17.12.2020 

It became clear that large parts of US (government) networks were hacked. To quote from the NYT article:

»The magnitude of this national security breach is hard to overstate.«

»The Russians have had access to a considerable number of important and sensitive networks for six to nine months.« 

 »The logical conclusion is that we must act as if the Russian government has control of all the networks it has penetrated.«

 To be clear: the fact that such a wide spread and devastating hack is possible is to a large extent the consequence of a very poor digitisation strategy and low execution quality. And it is certainly just to tip of the iceberg. 

Move fast and break things was finally successful: a lot of essential things are broken now. The more important answer was not given by Zuckerberg though: will we be able to repair this mess and who will pay for it? 

Addition on 28.02.2022 

The Russian war on Ukraine again stresses the point I tried to make two years ago. Over-reliance on actually unnecessary technology and the lack of alternate pathways — which are a fundament for resilience — celebrating simplistic efficiency, is getting back at us now. Let's learn from the damage as long as we still can: 

  • no unnecessary technology
  • the technology we deploy has to be well maintained
  • no single points of failure
  • no magic thinking (renewables will save our future etc)
  • no efficiency at the cost of resilience.

1 Kommentar:

palladion hat gesagt…

Thank you for the post, very interesting read. I think the following observation hits the nail on the head: "What an absurd twist of facts: suddenly we have to accommodate technology not the other way round: take care of peoples needs and ask, how technology could help."

Even usable security research that I am working in seems to focus on how to accommodate technology. Of course the issue is complex because he have to work with technology that is currently established and look for how to make it better for humans. However, I argue that even usable security research could do better and is instead too much focused on existing technologies and does not put the human at the center of new technologies (deployments).

In short, thank you for the article, it shows that it is both an important and a difficult issue we *have* to deal with.

Zum Abschluss...

Es freut mich, dass Sie sich die Zeit genommen haben, mein Blog zu lesen. Natürlich sind viele Dinge, die ich hier diskutiere aus einem subjektiven Blickwinkel geschrieben. Vielleicht teilen Sie einige Ansichten auch nicht: Es würde mich jedenfalls freuen, Kommentare zu lesen...

Noch ein Zitat zum Schluß:

"Ich verhielt mich so, als wartete ein Heer von Zwergen nur darauf, meine Einsicht in das Tagesproblem, zur Urteilsfindung von Gesellschaft und Politik zu übersetzen. Und nun stellt sich heraus: Dieses Heer gibt es nicht.

Ganz im Gegenteil erweist sich das kulturelle Getriebe als selbstimmunisierend gegen Kritik und Widerlegung. Es ist dem Lernen feind und wehrt sich in kollektiver Geschlossenheit gegen Umdeutung und Innovation.", Rupert Riedl, Evolution und Erkenntnis, Piper (1985)