The Artima Developer Community
Sponsored Link

Design Principles and Code Ownership
A Conversation with Martin Fowler, Part II
by Bill Venners
November 11, 2002

<<  Page 4 of 4


Strong versus Weak Code Ownership

Bill Venners: One of the other things you say in Refactoring in that same breath is, "This kind of thing you see in companies that have a strong sense of code ownership." What does code ownership mean, and what is bad about having a strong sense of it?

Martin Fowler: The way I look at it, there are three styles of code ownership. There is the XP style, which is sometimes referred to as no code ownership and sometimes as collective code ownership. In this style, no code is assigned to any particular person on the team. Anybody on the team can change any part of the system at any time. That's the XP approach.

The opposite end of the spectrum is strong code ownership. In strong code ownership, there's my code and your code. I can't change your code. If I want to change the name of one of my methods, and it's called by your code, I've got to get you to change the call into me before I can change my name. Or I've got to go through the whole deprecation business. Essentially any of my interfaces that you use become published in that situation, because I can't touch your code for any reason at all.

There's an intermediate ground that I call weak code ownership. With weak code ownership, there's my code and your code, but it is accepted that I could go in and change your code. There's a sense that you're still responsible for the overall quality of your code. If I were just going to change a method name in my code, I'd just do it. But on the other hand, if I were going to move some responsibilities between classes, I should at least let you know what I'm going to do before I do it, because it's your code. That's different than the collective code ownership model.

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.

Bill Venners: So the problem wasn't that these guys had interfaces to their subsystems, the problem was the interfaces were published.

Martin Fowler: That was the problem. They were publishing internally. If they had had weak code ownership, there would have been no problem.

Talk Back!

Have an opinion about duplication, explicitness, published interfaces, or code ownership? Discuss this article in the News & Ideas Forum topic, Design Priniciples and Code Ownership.


Refactoring: Improving the Design of Existing Code, by Martin Fowler with Kent Beck, John Brant, William Opdyke, and Don Roberts is at at:

To Be Explicit, an article by Martin Fowler first published in IEEE Software:

Public versus Published Interfaces, an article by Martin Fowler first published in IEEE Software:

The Pragmatic Programmer: From Journeyman to Master, by Andrew Hunt and David Thomas, is at at:

IntelliJ IDEA, a Java IDE with refactoring support:

Eclipse, an open source IDE with refactoring support:

A catalog of summaries of refactorings mentioned in the book, Refactoring:

A refactoring portal maintained by Martin Fowler contains links to refactoring tools and other refactoring sites:

Martin Fowler's links to extreme programming resources:

Articles written by Martin Fowler about XP and agile methods:

Patterns of Enterprise Application Architecture, by Martin Fowler is at at:

UML Distilled: A Brief Guide to the Standard Object Modeling Language, by Martin Fowler and Kendall Scott is at at:

Planning Extreme Programming, by Kent Beck and Martin Fowler is at at:

Analysis Patterns: Reusable Object Models , by Martin Fowler is at at:

Martin Fowler's website contains many articles, book chapters, and other information from Martin:

<<  Page 4 of 4

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use