I'm gonna' turn you into a rabbit | Cypress Semiconductor
I'm gonna' turn you into a rabbit
Humorist David Sedaris recently published the book "Squirrel seeks chipmunk", where the author excerpts, extracts and extrapolates the situations humans find themselves in and their behavior by writing tales where animals take on the actions and affectations rather than humans - he calls it a "bestiary" mostly because he never quite figures out the moral, and therefore he couldn't call them fables. And it works because not only does it hit home, but it lets one see familiar (usually bad) behavior one level removed, with painfully familiar animals acting out. (Full disclosure: I haven't read this yet, but I want to based upon what I have heard and read about the book. All points still apply, and maybe I can re-post after I do read it with some more comments.)
NPR's Morning Edition (Sedaris is a frequent guest and contributor to NPR) covered the book's release with an interesting segment not long ago that spoke with the author and about his book (listen or read it here: www.npr.org/templates/story/story.php). One particular exchange in the story struck me: "…one of the many flawed creatures in Sedaris' bestiary sends up a bully of a security guard he encountered at an airport security check. 'I just looked at her and I thought, 'I'm gonna turn you into a rabbit,' ' he remembers. 'So, I wrote a story about a rabbit who's put in charge of security in the forest.'"
Sedaris was able to concentrate on exploring the behaviors of individuals (probably many who were close to the author) by giving new names and species to the misbehavers. He separated the "products" of these individuals in a way that they could be examined without having to apologize to "them". Design and code reviews, too, are meant to focus on the product rather than the producer. As humans, at the top of the evolutionary brain chain, we say we can, but we seldom really succeed at effectively separating the two. What you see/hear is sometimes less important than who it comes from. How can this affect the results of a design or code review?
Positively: if you know and understand the quirks of the producer, you can adapt your review to catch his/her weak points. You can also save time not over-reviewing areas of strength.
Negatively: if a person's reputation is strong and positive and precedes them, the reviewers may not focus on the very details they are there to examine, thinking "this" person can't make "that" kind of mistake.
So I cannot help but find myself hoping for a situation where "squirrel" or "rabbit" are the names of the coders and the group of reviewers knows nothing about the coder, and instead they focus in on the details without prejudice. But what if the label "rabbit" meant more like in the old fable by Aesop instead of Sedaris' TSA clerk - where the character was quick but a bit sloppy and impulsive? Wouldn't that characterization help a reviewer know what to look for in his/her code?
The truth is, in most design groups the numbers are small enough that we will know each person well enough to let their character prejudice the review, but we must be keenly aware of those prejudices - and perhaps even invite input to break them when necessary or reinforce them when justified. If possible hold a pre-review meeting; let the producer/coder comment on what he/she thinks warrants a closer look, what have been problem spots in the past; then hold a group discussion without the coder about how the group can concentrate their review time. Sort of a review strategy session, determining how to maximize the results, but with a conscious view to what/why they are reviewing, trying to ferret out unproductive prejudices. As I consider past reviews and checklists I have been through, seldom (if ever) has a review consciously proceeded this way.
Modern marketing relies on our failure to isolate product from producer, building up and selling the brand first and foremost; product(s) usually come secondary or great product remain a "best kept secret" when there is no brand marketing. This works in general, but only if there is equal attention to product as marketing, and eventually fails when the product does not satisfy. But when it comes down to each human, the product almost always has to stand on its own every time, and the reviewers of code or a system design are the only safety net available.
Don't let "brand" blind you.