Does Satisfice Mean Agile?
Filed Under Software Process, Thought Stuff
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”?
One Response to “Does Satisfice Mean Agile?”
As Juval Lowy would say (in his thick Austrian accent): “Good enough is by definition… Good enough”