Satisfy + Suffice = Satisfice

The term satisfice was coined by Herbert Simon in context to economics, that is, that we will exert enough energy to reach the minimum level of acceptability in something but never reach the maximum potential.

Furthermore, Simon pointed out that human beings lack the cognitive resources to maximize: we usually do not know the relevant probabilities of outcomes, we can rarely evaluate all outcomes with sufficient precision, and our memories are weak and unreliable. A more realistic approach to rationality takes into account these limitations: This is called bounded rationality.

Because of bounded rationality and the never ending desire to accomplish things with the least possible amount of work – Is satisficing the heart of Agile?

The end goal in any software process is maximum ROI – NOT maximum results. Rewording, the end goal of any software process is maximum acceptability with minimal effort. With terminology such as KISS and YAGNI, is this not Agile?

Stepping away from feature development, what about the age old battle – what is an acceptable code coverage percentage? 70%? 80%? 90%? The laws to satisfice apply here as well. My vote has always been if you can not attain 100% code coverage your architecture is wrong; however, I always hear the same retort that there is low ROI in 100% code coverage. In the name of satisficing my point (and gracefully stepping away from this debate), for the time being, I will agree with that retort.

Are Agile processes truly embracing our human weaknesses thus allowing us to perform better, or are these processes teaching us a valuable lesson in satisficing in order to say “good enough”?

No this is not a post about the New Kids on the Block and their fantastic reunion tour.

Thought I would give a shout out to the “New Kid On The Block” – Jurgen Appelo.

He has been blogging fast and furious on his blog NO Operation: Complexity of Software Projects. Every single one of his posts have been pretty good. Here are my favs:

• Make It Simple vs. Do It Simple
• Complex versus Complicated
• MoSCoW Priorities

Better slow down there or you will burn out…save some for 2009!

Wow! I could have been a big hypocrite because I almost did this topic as a written post, but of course it should be a face to face whiteboard…

Be sure to check out Scott Ambler’s agile communication article as it was the basis for this whiteboard discussion.

So in summary, be sure to force conversations towards being more rich in nature and your time will be more maximized:

• Face to Face – Whiteboard
• Face to Face – Conversation
• Telephone Conversation
• Email Threads
• Documentation / Wikis