Cargo Cult Agile

It is instructive to consider human tendency towards magical thinking that finds a wonderfully didactic expression in Cargo Cults.

Magical thinking fundamentally expresses faith that performance of certain rituals alters the status of the actor and can confer benefits that are not correlated with the substance of the ritual itself.
It is not difficult to find many examples where application of Agile is an exercise in ritualistically following the form rather than focusing on substance.

The original intent of Agile was to redress the balance of power between managers/stakeholders and engineers, affording more power to the latter, and achieving better results & productivity through their empowerment.

But it is not uncommon today to find instances where Agile became co-opted as just another mechanism of control, without altering the power equation, and rests on what amounts to a magical belief that by performing formal ceremonies and rituals of Agile, the benefits will accrue even if such performance is entirely divorced from its underlying rationale.

The very same powers that demanded of engineers compliance with rigors of waterfall-style development, simply switched the rulebook and now demand compliance with the rigors of Agile. Such hollowed-out Agile practice remarkably resembles the cargo cults I referred to at the start.

On Well-Designed Event Models

I propose that events composing a well-designed event model should be of a form:

Where:

• E_Ai^x→y is the event communicating transition of aggregate/entity A_i  from business state S^x to business state S^y

• A_i is the i-th instance of aggregate or entity A consisting of attributes {α, β... ω} 

• State transition (S^x → S^y) is accompanied by changes in a subset of attributes of A_i {α, β... μ} to new values {α', β'... μ'}, these new values (if required, with previous values {α, β... μ}) are included in the data payload of the event E_Ai^x→y{α', β'... μ'}

This approach is in contrast with a trivial event model where events are simply attribute-level changes, e.g. instead of emitting E_Ai^x→y{α', β'... μ'}, emit the following series:

Ergo, developing a business state-centric event model requires starting with business state transition diagram for entity/aggregate A:

The benefit of business state-centric event model is to make explicit the state transitions (which typically involve changes to more than one attribute), instead of those having to be inferred/reconstructed by the consumer of attribute level events E^α_Ai {α'} = A_i {α'}.

The Why of Explainable AI

AI is all the rage today. And ARPA is investing into explainable AI - why?

I believe the key for us, humans, is to be able to have recourse to another human who, we viscerally feel, may understand our situation and have empathy, based on shared experience and understanding of the world and how we - mortal, fallible humans - interact with it.

So no matter how sophisticated the AI, will we ever trust it to understand us enough that we will not wish to have recourse to the judgement of another human with power to overrule the "Computer says NO"?

But, how would a human "appellate judge" be able to evaluate AI's decisions if they're a mystery concealed within the deep neural network, acting on more data than a human can readily deal with?

Hence the need for the explainable AI.

I will leave it as an exercise to the reader to infer what types of use cases ARPA might be interested in, where robotic judgement might need to be subject to human appeal.