UML helps you prevent your brain from exploding

Yep, UML helps you keep your head. Just take an actor in a use case diagram. Why is it a stick figure? Perhaps because we are not artists. Imagine having to draw whistler's mother everry time we're representing a user. Go ahead, we'll wait for you to imagine how hard this would be.

What about class diagrams? Think about it for a second, based on how hard it is to imagine a couple thousand lines per class of spaghetti (just  100 lines lasagna if you are good programmer). A class diagram symbol is just a symbol. At most we define name, attribute and method signatures. We do this for good reason. To add more detail implies we actually can absorb, understand, and remember the complete program.

The facts are, we are sloppy and lazy. We can't keep  more than a few things in our heads at one time. Sure we match patterns, but not thousands of lines of Java at the same time. We think linearly. We also are not savants with photographic memories.

Sorry, no idiot savant here. We need a crutch. That's UML.

Developed by nerds, not artists, UML is a cartoon of symbols, not a detaied 3d representation. UML is ugly and unimaginative. Ugly is good. You don't buy ugly a new car from irrational imaginings of a good time.  Ugly is functional.

People complain that UML is confusing. Sure, that's true, but only if you don't understand UML, or objects, or in fact have the ability to abstract life and the world. UML is just a language of symbols. You need to learn to read and write before the alphabet is really useful.

Ok, enough. Go learn. We'll be waiting.

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.