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?


EditText of this page (last edited September 29, 2003) or FindPage with title or text search