An Anti Pattern
Sticky Fingers 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 Sticky Fingers 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 No Go Area 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 Sticky Fingers 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.
See original on c2.com 