Proof of Life

Avoid addressing problems, issues, events, or constructs that are not proven to exist in the real world. This is like "proof of life" used in hostage negotiation. Here you should not proceed until there is proof that the need either exists or there is a commitment to existence.

Proof of life or existence of a concept in the real world should be confirmed before allowing a concept to be added to the process or metadata. Simply, there are things we imagine that might exist that do not exist in reality. Imagination and antidotal-based evidence lead us to create scenarios that are not realistic. We need to limit effort based on impossible or rare edge cases.

Dealing with edge cases and error conditions is important. How exceptions are dealt with can be designed so that the effort is applied at the exception, rather than designing expensive infrastructure to solve a problem that may never occur.

We hate failure and that is why we come up with many scenarios that may only be imagined. If something might happen, we believe it actually does happen. The difficulty is proof that will satisfy a critic. The best case is that without proof, we cannot assume it is necessary to address or that we address with a lower level of effort. Those things that have definitive proof have priority.

It is important that our primary modeling tool is UML-based with UPDM, SysML and other standards. These give us all the building blocks and levels of abstraction so that we avoid reinventing the wheel. We also have one place to look for what we have proved to exist and even what does not. Unlike cowboy-agility where we erase the whiteboard on every iteration, we have a history that gets smarter after each iteration. Don't be afraid to document an activity and add metadata to classify it as 'do not implement.'

Address primary use cases and important edge cases, but should not attempt to address those that cannot be proved. There may be guidance for addressing such unknowns and ensure that efforts are reviewed to ensure success.

A good test of "Proof of Life" is a repeatable and complete test. If you can create a test, then it is at least possible to show the exception in practice. This works well for software, but also applies to your development process and any automation and metadata of the process.