The analysis of competing hypothesis (ACH) is an investigation technique used to handle evidence in the domain
of national security to fight bias and preconception as well as to ask the right questions. This technique
can be applied to software development! We will walk/code through a simulated „component blame game“
scenario where change is introduced into an existing software system not necessarily built for resilience towards
change and we‘ll use ACH to bash some serious potential screw-ups.
Target Audience: Architects, Developers, Whoever has seen a bug from hell in the past and did not find it funny
Prerequisites: Basic software architecture principles, Basic Java
You will learn:
You'll learn a simple looking, but powerful way to get "unstuck" when a dead end is reached and to tidy up when things get complicated. This is about logic, guesses and evidence; it is a generic investigation method that may come in particularly handy in software development.
Hunting an elusive beast that lurks in some dark corner of your production system and probably has been rummaging undiscovered though your network of connected things for heaven knows how long … is the sort of experience most of us can do without, but have sooner or later to endure.
Paradoxically, the bugs from hell rear up their ugly heads exactly in the parts of your architecture you really did not think of looking at in detail, with an almost invariably immaculate timing, so that the crisis hits when you really don't need it and where you really don't expect it… mostly at production transition time a.k.a. going live.
To our knowledge there is no tool or method capable of finding this type of problem for you, but we do know of a set of methods from intelligence analysis that you can use to put both what you know and what you don't know to profit and dramatically improve your chances to get out of this sort of situation in one piece.
The analysis of competing hypothesis (ACH) has been used in intelligence for decades to handle evidence and has helped many analysts in the domain of national security to fight bias and preconception as well as to ask the right questions.
We will walk you through a simulated practical "component blame game" scenario where change is introduced into an existing software system not necessarily built for resilience towards change in the first place and we'll use ACH to bash some serious potential screw-ups.