I've been talking a fair amount about cognitive science lately, particularly with regard to its relationship to usability / user interaction and with the nature of programming as a profession.
The former relationship should be reasonably obvious - users are human (we hope... most of them anyway, even including pointy-haired bosses), and if we want them to use our software we have to create it with interfaces that are easy and useful, taking advantages of the quirks (strengths and weaknesses) of human thought. We need to know, accept and embrace not only that users want things to happen quickly, but that they need to be named and labeled in ways that will make sense to them at first glance WITHOUT thinking about them. (There's a reason why Steve Krug's usability book is titled "Don't Make Me Think".) Unlike programming tools, we need to make most decisions for our customers in advance based on common assumptions about what our users are LIKELY to do, not what they MIGHT want to do (you handle the "might wants" with additional tools on the back-end, not by forcing them to make decisions up-front).
These are all lessons that Microsoft and Seapine have yet to learn, despite their years of operation. Although the creators of Subversion and TortoiseSVN have learned them! Where Seapine's "mature" Surround SCM is constantly bonking me on the head with a librarian's desk-reference, with numerous annoying dialogue boxes that I mostly don't use any time I want to as much as glance passively at a file, TortoiseSVN only shows me a dialog when I ask for one, and provides me with helpful information up-front (files not currently checked in when committing) that's impossibly buried in the Surround SCM client.
But although I constantly champion the notion of programmers improving their usability skills, this article isn't really about that. This article is about understanding cognitive science so that we can have a better understanding of our own habits and the reasons why some things repeatedly bite us in the ass. What's most interesting and ironic to me about cognitive science is that programmers are CONSTANTLY talking about it ... they just don't know that they are. I actually didn't know much of anything about cognitive science until this past year or so. I started reading books like Dan Ariely's predictably irrational and I realized that, although I have in the past been rather snarky to Larry Lyons on the cf-community mailing list, I probably should have been asking more questions! Although I'm not sure what his official degree status is, Larry studied behavioral psychology in college.
So why all the hubbub?
It's important. It may be more important than studying programming theory or design patterns!
Why?
Consider that your mind is merely a program that's been designed by millions of years of evolution. That program has evolved a number of its own design patterns - ways in which the mind works relatively consistently. These design patterns have evolved over these many millions of years to produce people like you and I who are very well adapted to survive and even thrive in a ... NON-AUTOMATED world. By this I mean to emphasize that we have not evolved to be good at programming computers - far from, computers if anything seek to replace the tools we've naturally evolved for survival in a pre-modern world. So our mental machinery isn't designed for programming - it's designed for things that are far less abstract and as a result, what "works well" for programming computers is often very different from how we've evolved to think.
So where does that put us?
Programming computers without at least attempting to understand cognitive science is like taking a cave man, sitting him in a Swiss watch factory (pre-quartz) and expecting him to assemble fine time-pieces with no training. His brain hasn't evolved to handle it and so he'll work on those watches using the same design patterns that evolved for him to work on hunting and gathering for food. Will he eventually figure it out? Yeah, sure. But the quality of his product will be sub-standard.
Cognitive science is the training to understand the brain's built-in design patterns and how to apply them (or more importantly avoid misapplying them).
What's happening in the software industry is that a lot of people are talking about cognitive science. In fact, they're RANTING about it all the time! They just don't know that's what they're doing. And they're demanding that things change, without first trying to understand why they are this way already! They're looking at the cave man in the watch factory and they're wagging their finger at him and shouting "shape up! You need to produce better quality!" But they're not offering him the training that would actually help.
Here are a few examples:
Every single one of those articles should have made some mention of cognitive biases... yet none of them did.
And I'll go a step further and I'll give another example from my own experiences. Over the years I've received a number of emails saying "x is bad" or "x is a bad idea" ... If you read the above examples, you can see some of that with regard to the "active record" design pattern. The problem is that "active records are bad" is the way our brain is designed to think -- it's simple and it's concrete. The reality is at the extreme opposite end, much more akin to what Sean Corfield says in response to the question "which is the best framework to use", i.e. "it depends". The question "which is the best", sets up the other person with the expectation that you'll give a singular answer - simple, concrete, the way we're designed to think - irrational. The active record design pattern can't be good or bad outside of some context. Every design pattern exists for the purpose of addressing a specific problem or set of problems - they have advantages and they have drawbacks or "consequences".
It's important to note that the evolution of human thought bears no resemblance to "logic". There are logical reasons for our having evolved to think in particular ways. Those reasons are obscure and counter-intuitive. Moreover logic itself has never been a survival strategy for a species. The fact that we can be logical or rational doesn't mean that we are very often, particularly because logical thinking isn't really an advantage to our survival. Logical thinking doesn't much help the cave man to find food or avoid predators. Our "irrational" gut instincts are much more effective at managing those tasks. Similarly logical thinking in the face of an irrational, pointy-haired boss generally doesn't win you brownie points at work either.
As such we've evolved certain design patterns like a "herd instinct". Other people (not myself) will lambast humans in general for even having a herd instinct, referring to them as "sheeple". I don't take that approach. I prefer to think of the herd instinct as "friendliness" and "social cohesion" - it is what allows us to build communities and do big and bold things like building projects that took more than a generation to complete. If not for our desire to band together, none of those projects would have gotten off the ground! It is a good strategy for those things. But my desire isn't to blame people for thinking irrationally ("sheeple"), it's to understand how and why we think the way we do and to encourage others to study thinking as well as a means of not just improving, but elevating our work.
The consequence of herding of course is that it's not a great strategy for growing a society of "free thinkers", leading us to the comments Machiavelli wrote about "innovators" in his biting satire the Prince. The effect of confirmation bias means that we tend not to think of the drawbacks or "consequences" of design patterns. We tend only to think about how they solve our problems. So what are some of the other drawbacks of the "herd instinct" design pattern? It discourages good programmers from implementing great new and innovative solutions to age-old problems for fear of reprisal.
Here's an example from outside the software world. Rabies has been a death sentence since men first started walking upright, and there's still no truly effective treatment. Jeanna Giese is the worlds first full-recovery from rabies. Her doctor had never seen a case of Rabies before, and it's probably a good thing! If he'd been a rabies expert, she would be dead! Why? Because the conventional wisdom in the field is that there is no hope for rabies victims. The standard treatment is pain-killers. And although she is a fantastic example of both the outsider effect and the problems of relying on our education, when Dr. Willoughby spoke about his Wisconsin Protocol at the international rabies convention, other highly respected doctors told him that it shouldn't be used until there is laboratory evidence of its effectiveness! And this is a condition in which, the alternative is guaranteed death!
That kind of fantaical, devout and thoughtless reprisal is hard to swallow. It's precisely what Machiavelli was talking about in the Prince.
There's something else that comes out of the example of Willoughby's rabies protocol, and here's a real kicker. These doctors are also not learning the lessons of cognitive science. Well why should they? They're physicians, not psychologists! And they're doctors! They're beyond all that mushy stuff that gets in the way of either real science of helping the patient.
Aha! But that's the problem in a nutshell.
The fact that we (doctors and programmers) think we're above or beyond the problems created by cognitive bias is merely another example of cognitive bias! And it's the real crippler. It's called the overconfidence effect. Nearly everyone, without respect to age, sex, religion or PROFESSION, believes themselves to be less susceptible to dangers than anyone around them. Every smoker believes they're unlikely to get lung cancer. Each of us (myself included) believe ourselves to be more rational and more logical than our peers... but we're not.
The problem here is that the "overconfidence design pattern" has been quite effective for us in the past in helping us to thrive as a species in a pre-modern world. It does not however help us to program computers, in fact, it hurts us. We're apt to look at a blog entry like this one and think "that's interesting, but it doesn't apply to me -- I always judge the pros and cons of design patterns appropriately". Do you? It's not likely. It's not likely that Hal Helms does or Sean Corfield, Joe Rinehart, Matt Wooward or Peter Sommerlad.
That's the reason why we end up with blog entries that say things like "active records are bad". Really? That statement makes no sense. It's a result of the oversimplification design pattern. Without a context of the problem it's being used to overcome and the impact of its consequences on the remaining application, you can't say that they are good or bad. What's bad is slavishly applying them where they're not very useful or slavishly avoiding them where they would be.
It's that slavishness that causes Java programmers who come to ColdFusion to complain about its STRENGTHS like its lack of strict-typing or for any programmer to praise the virtues of case-sensitivity. (See Sean Corfield's CFUnited presentation. Heresy! Embracing Duck Typing in CFCs.)
And THAT slavishness is a result of the design patterns in your brain!
Cognitive science.
I CAN'T stress it ENOUGH.
