TITLE: Quick and Wrong and Fast and Slow AUTHOR: Eugene Wallingford DATE: December 08, 2011 4:23 PM DESC: ----- BODY: I've been reading a lot about Daniel Kahneman's new book, Thinking, Fast and Slow. One of the themes of the book is how our brains include two independent systems for organizing and accessing knowledge. System One is incredibly fast but occasionally (perhaps often) wrong. It likely developed early in our biological history and provided humans with an adaptive advantage in a dangerous world. System Two developed later, after humans had survived to create more protective surroundings. It is slow -- conscious, deliberative -- and more often right. One reviewer summarized the adaptive value of System One in this way:
In the world of the jungle, it is safer to be wrong and quick than to be right and slow.
This phrase reminded me of an old post by Allan Kelly, on the topic of gathering requirements for software. The entry's title is also its punch line:
You are better off being generally right than precisely wrong.
These two quotes are quite different in important ways. Yet they are related in some interesting ways, too. It is easier to be fast and generally right than to be fast and precisely right. The pattern-matching mechanism in our brains and the heuristics we use consciously are fast, but they are often imprecise. If generally right is good enough, then fast is possible. Attempts to be slow and precisely right often end up being slow and precisely wrong. Sometimes, the world changes while we are thinking. Other times, we end up solving the wrong problem because we didn't understand our goals or the conditions of the world as well we thought we did at the outset. Evolution has given us two mechanisms with radically different trade-offs and, it turns out, a biological bias toward quick and wrong. When I talk with friends who dislike or don't understand agile approaches, I find that they often think that agile folks overemphasize the use of System One in software development. Why react, be wrong, and learn from the mistake, when we could just think ahead and do it right the first time? In one way, they are right. Some proponents of agile approaches speak rather loosely about Big Design Up Front and about You Aren't Gonna Need It. They leave the impression that one can program without thinking, so long as one takes small enough steps and learns from feedback. They also leave the impression that everyone should work this way, in all contexts. Neither of these impressions is accurate. I try to help my skeptical friends to understand how a "quick and (sometimes) wrong" mindset can be useful for me even in contexts where I could conceivably plan ahead well and farther. I try to help them understand that I really am thinking all the time I'm working, but that I treat any products of thought that are not yet in code as contingent, awaiting the support of evidence gained through running code. And then I let them work in whatever way makes them successful and comfortable. I think that being aware of the presence of Systems One and Two, and the fundamental trade-off between them, can help agile developers work better. Making conscious, well-founded decisions about how far to think ahead, about what and how much to test, and about when and how often to refactor are, in the end, choices about which part of our brain to use at any given moment. Context matters. Experience matters. Blindly working in a quick-and-generally-right way is no more productive approach for most of us than working in a slow-and-sometimes-precisely-wrong way. -----