Wrapping up our first pass at Development Project Archetypes we look at a common culprit on brownfield teams.

During your first week on the project you’re assigned to have a mentor who has written a large portion of the existing application. While working on your first serious defect in the system, you ask the Possessive Developer about an existing piece of code and suggest refactoring. She looks back at you and states “There’s no reason to change that code. It works just as I want it to.” After explaining its deficiencies, the Possessive Developer is sullen and in a less-than-cordial mood. At the end of the conversation she has neither agreed nor disagreed with the suggested changes, but there is tension in the air.

The following morning the Possessive Developer corners you at the water cooler and lashes into a list of reasons that there should be no changes to the code discussed the previous day. At the end of the one-way conversation she walks away with confidence in her stride. You now know. It is her code, her creation and her domain. Only the Possessive Developer can state when her code is to be changed.

Like the “Oooo…Shiny!” Developer, code reviews with peers can be useful. In a more neutral forum, it’s much harder to argue against the majority. But don’t ignore The Possessive Developer. It doesn’t take long to turn her into a Skeptic or a Hero.