Picking At Scabs

PickingAtScabs happens when a design team gets together and argues out issues that have already been discussed a hundred thousand times. Everyone in the room cringes when the subject is mentioned, but it just keeps coming up.

Why?

Because the previous hundred thousand conversations did not result in a solution that was understandable to all the various parties involved.

What might be a better solution?

Perhaps referring to standards, which are really the end product of letting somebody else go sit in a room and pick at scabs so you don't have to. Also helpful would be an agreed-upon vocabulary and an easily searchable library of good solutions (gee, this sounds like a pattern). This would short-circuit the scab picking by basically saying, "those guys already talked about this and came up with a solution that works. Use CopyAndPasteProgramming and puhleeeeze move along to the next subject."

This often happens with groups that have never reached a consensus on how decisions are made. That is, they've never decided how to decide. Once a team has agreed on a protocol for making decisions - a challenging bootstrapping process in itself - there are fewer opportunities for leaving scabs.

See RomanEvaluation for one of many team decision protocols. -- DaveSmith

That points out one of the major reasons. When I am PickingAtScabs it's generally for one reason - programmers in the group follow the MicrosoftProgrammerMentality.

-- ThaddeusOlczyk

No, not at all. If the same business problem or component of the business problem already has a good solution, then if that solution could be retrieved it could be reused, avoiding the constant replowing of the same ground. This would require a common vocabulary of description, and some means of cross-referencing so that a description of a current problem would retrieve existing solutions to same or similar problems. Also, about DaveSmith's comment on reaching consensus: PickingAtScabs occurs when one specialty of software designer refuses to respect the professional recommendations of another specialty. One reason this happens in UserInterface design is that there is not (yet) a standardized language and structure for reaching the HumanFactors design decisions. Since the process involves defining the interface to a highly variable, erratic, inconsistent external system (a human), the methods of reasoning used to arrive at a solution are not readily quantifiable; and we all know that engineer/programmer types crave quantifiable, repeatable, structured solutions. There is no RationalRose type tool to define the interface structure - that's what is missing. -- DebRrose

"Recommendations" are easy to see as "dictates" when there's no feedback loop in the decision making process that allows one to express an opinion. It is a tough way to be involved. Values of communication links are out of whack so data sends occur but usually inefficiently or ineffectively.

CategoryAntiPattern CategoryDelightfulMetaphor?