Designing Anti-fragile Systems - Case study: Uber Autonomous driving Accident

In my previous post, we discussed principles that can be used for designing Anti-fragile systems.

There were some feedback that the case study was not easy to relate and understand the principles better. With the spirit of making it easier for all of us - including me - to understand, I am taking a very recent and relevant case study to understand Anti-fragile systems.

A relook at the principles

For a more detailed understanding of the principles, please read here: https://madhavanwrites.blogspot.in/2018/03/principles-for-developing-systems-that.html

• The Customer
• Our highest priority is to satisfy the customer by building non-linear , pro-active and self-adapting system.
• The Context
• We welcome changing scenarios where unexpected events are the real paradigm shifting entities.
• The Tolerance
• We deliver assuring embedded and adaptive fault tolerance.
• The Stakeholders
• All stakeholders, and the broader environment, lead the antifragile organisation.
• The Team
• Build antifragile projects around motivated, skilled and open minded people. Give them  the environment and support they need, and trust them to get the job done.
• The Communication
• The most efficient and effective method of building an antifragile org is building honest, open and transparent communication
• The Exposure
• Continuous exposure to faults and automatic fixing is the primary measure.
• The Maintenance
• An Antifragile org promotes a context aware environment. The stakeholders should be able to maintain a system indefinitely.
• The Dimensions
• Continuous attention to technical excellence , reality and redundancy.
• The Error
• Error loving - the art of learning to be antifragile  - is essential
• The Architecture
• Antifragile architecture emerge from self-organising , context aware teams.
• The Reflection
• At regular intervals, the developing team reflects about the context situation, on how to become more effective, then tunes and adjusts its behaviour accordingly.

The case study

Uber has been running experiments on autonomous driving around several cities - including Pittsburgh, San Francisco, Toronto and Phoenix.

It has been involved in an accident that has resulted in a fatal pedestrian casualty. Post this incident, let us look at this from the lens of designing an antifragile system and what could we have done better.

• The Customer
• The customer is the driver behind the wheels of an autonomous vehicle. The design of the experiment has been to provide all the necessary inputs. However, the system is not self-adapting. It does not learn - yet - from how the customer reacts behind the wheel and drives accordingly. 
• In this case, we could have had a system where the speed could be varied based on how attentive the driver is since this is still not a level-5 autonomous ssystem

• The context
• The system has been designed very well to handle several unexpected events. Over a period of time, the entire experiment has been rolled out to handle several edge cases.
• What the system lacks is a mechanism to look at these unexpected events as entities themselves that redefine these programs.
• What we should be doing is to have had more testing in multi-use road environments that could have provided these inputs earlier.

• The Tolerance
• The ability to handle faults - or rather tolerate them - is definitely missing in this case.
• In this case, there does not seem to be a provision in the system to report and learn from any errors. Errors . that could be easily attributed to manual errors, are inputs and need a way to be recorded in this system

• The Stakeholders
• This system needs an environment that engages with all stakeholders - that is its source of errors.
• In this case, there are several regulatory agencies and other bodies that have been resisting autonomous driving citing lack of tech maturity and several others have been taking an ethical stand as well. 
• Several autonomous driving companies have handled this by isolating each stakeholder and addressing their concerns by limiting the inputs themselves.

• The Team
• The team that works on autonomous technologies in Uber - and in other autonomous driving tech companies - are some of the most open teams that I can see.
• It is critical that they get the environment that gives them trust and motivation. What they need is critique not criticism.

• The Communication
• Team communication is critical. Developing some of these bleeding edge tech needs clear communication and a honest transparent culture.
• The teams seem to have evolved into a honest transparent culture with a good sense of responsibility.

• The Exposure
• Exposure is critical to any system to become antifragile. Clearly that is missing here.
• We have discussed this point in some detail in the stakeholders part. Exposure to the autonomous tech is very limited and stakeholders are typically isolated.

• The Maintenance
• While the experiments and the autonomous tech company is not designed today for constant evolution, that seems to be a by-product of the recent events. 
• I sincerely hope that Uber and all of its peers design systems that look out to maintain some of its characteristics rather than depending on the unfortunate events that have taken place

• The Dimensions
• The technical excellence dimension is very well understood by Uber. However, what is lacking is a good understanding of the other 2 dimensions - Reality and Redundancy
• It would have been great if the engineers and the managers at Uber prioritised what was necessary for the autonomous tech program in terms of having a antifragile system that satisfied the customer rather than moving forward with business goals.
• Similarly, Non-linearity of experiments take a toll as well. Redundant and small experiments that are exposed with multiple stimuli - that could be similar - is badly needed for the system to be antifragile today.

• The Error
• This system today lacks a way to handle errors properly.
• An example is that the car could handle all errors - unexpected inputs - by probably stopping. It could reduce speed if some or most of its sensors are not sensing anything.

• The Architecture
• The ability of teams to self-organise for processing inputs better is very critical.
• We have not seen any evidence of that so far in Uber's case. Let us hope they find a way to self-organise to be more aware of the context and get inputs.

• The Reflection
• The ability of the team to reflect on past outcomes and learn from that is critical.
• Uber has shown a lot of grit in learning from past outcomes. 

Conclusion:

While Uber, as an autonomous tech company, has shown maturity in certain aspects of having an antifragile system, It needs to have a far more maturity in several critical aspects - the most important of which is Error and Stakeholders.