The Zen of Decision Making

I copied the following nineteen zen-like koans from the website devoted to the Python programming language (don't leave yet...this isn't really going to be about programming!).

• Beautiful is better than ugly.
• Explicit is better than implicit.
• Simple is better than complex.
• Complex is better than complicated.
• Flat is better than nested.
• Sparse is better than dense.
• Readability counts.
• Special cases aren't special enough to break the rules.
• Although practicality beats purity.
• Errors should never pass silently.
• Unless explicitly silenced.
• In the face of ambiguity, refuse the temptation to guess.
• There should be one-- and preferably only one --obvious way to do it.
• Although that way may not be obvious at first unless you're Dutch.
• Now is better than never.
• Although never is often better than *right* now.
• If the implementation is hard to explain, it's a bad idea.
• If the implementation is easy to explain, it may be a good idea.
• Namespaces are one honking great idea -- let's do more of those!

The koans are supposed to communicate the essence of the guiding principles of programming. Their zen-like fashion is intended to motivate reflection and discussion more so than state explicit rules. In fact, there is a twentieth unstated (Or is it? How's that for zen-like clarity?) principle that you must discover for yourself.

Good aphorisms often find meaning beyond their initial intent. That's the way general, somewhat ambiguous guidance works and why some aphorisms last for so long in common parlance. They're malleable to one's circumstances and provide a kind of structure on which to hinge one's thoughts, concerns, and aspirations (I'm pretty sure horoscopes and Myers Briggs work this way). Some of these aphorisms, maybe all of them, struck me as not only useful as guiding principles for programming but also for decision management in general. Seriously. Go back and consider them again, Grasshopper.

So, let me ask you:

• In what way is decision management like programming?
• How would you interpret these principles, if at all, for use in the role of decision making?
• What do you think is the missing principle?