DenkzeitWiki

Main /

Code Ownership

BeingAGoodProgrammer
CodeQuality
MaintainableCode

• XP myth dispelled: no code ownership

Collective code ownership means everyone accepts responsibility for the quality of the code. This means that everyone pulls in the same direction or there is chaos, and that chaos bubbles to the surface very quickly. [1]

• http://c2.com/cgi/wiki?CodeOwnership
  
• Collective code ownership is limiting software quality
  • Specialization is necessary
  • Implementation-details better not known to the consumer
  • know what to not know
  • -> code ownership

---

• http://martinfowler.com/bliki/CodeOwnership.html
• Strong code ownership
  • no one but the owner changes code
    • delays, even on simple changes (renaming a variable)
• Weak code ownership
  • developer (owner) is responsible for changes other devs make to her code
• Collective code ownership (Shared Code)
  • code is not owned individually, the team owns all the code
  • Collective Code Ownership @ ExtremeProgramming
  • UnitTests are important here (so nothing breaks on changes), ContinuousIntegration also helps
  • Everyone codes everywhere - don't work on the same part of the system for a long time
    • Everyone can code everywhere - shifting man-power when needed.
      • http://c2.com/cgi/wiki?TruckNumber
        

Weak and collective seem to work equally well (and fail equally often) - it's about the social dynamics of the team.

• Design Principles and Code Ownership - MartinFowler

Weak code ownership and refactoring are OK. Collective code ownership and refactoring are OK. But strong code ownership and refactoring are a right pain in the butt, because a lot of the refactorings you want to make you can't make. You can't make the refactorings, because you can't go into the calling code and make the necessary updates there. That's why strong code ownership doesn't go well with refactoring, but weak code ownership works fine with refactoring.

• Collective Ownership of Code and Text - WardCunningham

It was a turning point in my programming career when I realized that I didn't have to win every argument. I'd be talking about code with someone, and I'd say, "I think the best way to do it is A." And they'd say, "I think the best way to do it is B. I'd say, "Well no, it's really A." And they'd say, "Well, we want to do B." It was a turning point for me when I could say, "Fine. Do B. It's not going to hurt us that much if I'm wrong. It's not going to hurt us that much if I'm right and you do B, because, we can correct mistakes. So lets find out if it's a mistake."

And then the developer says, "You know, I'm sick of working on this code." I say, "Hey, I'll take that bug." And they say, "Would you?" I say, "Sure, I'll take the bug. You did B. I'll work on B." So I can go in and work on it, and I'll try to use as much of B as is worth using. But with taking on the responsibility, I get the opportunity to make it do what it needs to do.

---