You probably know the rest of this quote, but likely have no idea where I’m heading with it. Well, it’s a brief conversation about making snap judgments.
At a client recently, we were discussing the effects of code coverage, code complexity, code dependency and other automated analytics and whether developer testing actually improves the ability of a company to effectively deliver software applications.
I was internally amused when a developer said, “This one time, we hired a guy who was a big-believer in JUnit, but his code wasn’t any better than mine.”
That was his objection. In total. One time he was underwhelmed with a colleague, so he really shouldn’t give any credence to reconsidering the topic.
It might be laughable if it wasn’t common. In fact, as a society we promote the idea of quick, intuitive decision-making. Malcolm Gladwell’s book, Blink: The Power of Thinking Without Thinking is a great example of modern trends about instinctive reasoning.
I, personally, love the byline of Jerry Adler’s review of the book How Doctors Think: “Snap judgments are cool, except when they’re wrong.”
The concept of “diagnosis momentum” in medicine is not dissimilar to development teams who are myopic in evaluating how they produce software. The best answers are found when you move forward with “deliberation, caution and systematic thinking.”
The next time you suggest a new change to your team and a fellow member starts an objection with, “This one time,” I hope you remember the “band camp” scene from American Pie. Try not to laugh out loud, but do try to challenge the notion that such a limited experience set is not of great value when contemplating change.
So, what’s your experience? Do you work with colleagues that often have an objection based on single-case experiences? Are they influencers or ignored? How do you lead them towards more deliberate examination?
May 30th, 2007 at 4:53 pm
Kathy Sierra has a great blog entry called “When only the glib win, we all lose” at
http://headrush.typepad.com/creating_passionate_users/2006/04/when_only_the_g.html
that describes a tendency of listening to “fast talkers” that sound smart.
May 31st, 2007 at 5:10 pm
This kind of behavior reflects a fairly common cognitive bias: one anecode tends to beat reams of data — especially if it’s your own anecdote.
June 1st, 2007 at 7:08 am
I think the underlying problem is that people don’t see how it can help them. Implicit in the “This one time…” story is that it’s somehow normative — in other words, that there is no theoretical advantage to unit testing, and so this one case is simply confirming evidence.
The best approach I’ve found to improving process with developers is to approach reflection as debugging the business system. Any time spent with developers not writing new functionality can be identified as a bug: adjusting business processes (including adopting new development standards, implementing new tools like CI, and changing the relationship with the customer) are the way the system is patched. Debugging is something that developers are good at and comfortable with, so it really brings the problem into their paradigm.
June 1st, 2007 at 9:50 am
@Robert Fischer: I think you are right - there is not enough “proof” that adopting the right behaviors will result in the desired outcome. A common challenge when talking about the adoption of coding standards, for example, is “where’s the academic research that proves that applying standards reduces defects?” In the absence of such proof, people are prone to use single-case examples to prove their point.