An AntiPattern StickyFingers refers to the practice of assigning responsibility for a piece of code to the last person to touch it. The practice often develops in resource-scarce environments, where * the size and balance of the engineering organization hasn't grown to keep up the maintenance requirements of the code they're developing, or * a substantial amount of externally developed code is brought in-house, or * the organization has lost key developers, either through normal attrition or through downsizing Practicing StickyFingers ownership leads to some interesting behaviors: * When a volunteer is asked for, a group of engineers will take a collective step backwards * Developers whose sense of responsibility has not developed to the point of understanding that they're not doing anyone any good if they're dead will end up stuck with a crushing amount of work * Some developers will develop clever ruses for sneaking in changes to ownerless code without leaving identifiable fingerprints The situation can degrade to the point where merely mentioning a problem in a NoGoArea can be seen as an invitation to take on responsibility. Conversations go strangely quiet if they drift too close to an unowned artifact. Problems don't make it on to management's radar, leading to nasty surprises when a project goes in to testing. In some cases, a crisis eventually forces management to deal with resourcing issues, often through dropping support for some aspects of a product line. One good test for StickyFingers problems is to take the feature set touted in the Marketing brochure, and attempt to match developer (or project lead) names against the features ''by asking the developers'' which parts of the system they're responsible for. Make a second pass if there are gaps in coverage. Ownerless code isn't always a problem, but if, when asked about gaps, developers avert their gaze and mutter something about needing to be off for a meeting, take this as in indication that you have a problem. --DaveSmith ---- CategoryAntiPattern