|Reactions: Code Ownership, Integration, Workspace,
Release Schedule, and Coding Standards
|We explore several practices in XP, exploring
alternative models and their consequences, and review the reasons for XP's
- Code Ownership: Who can change an object that needs to change?
- Integration: How and when does a team ensure everybody's code
- Workspace: How should a team be physically arranged?
- Release Schedule: How often should a team release their
- Coding Standard: How should the code be written?
For some systems, nobody owns the code. For closed-source systems, maintained
by a third party, "nobody" just means "nobody here". There are other programs
that are untouchables: there's no source code (it was lost years ago), or the
system is too brittle or too complicated to safely change.
When code isn't owned, developers will either design around it or treat it as
a black box. That latter approach can be especially painful: the programmer has
to format data going in and out; they may have to mediate between two paradigms
(e.g., using screen-scraping technology); they may be unable to do things you
would normally expect to be possible; there may be data denormalization and
coordination problems because information has to be stored both inside and
outside the system.
Avoid the situation of "nobody owns it (and nobody wants to)".
Last One Who Touched It ("Tag"); and
Whoever's Newest ("Trial by Fire")
You may have systems that are reasonably stable, but still a pain to
maintain. In these situations, there's typically a local cultural rule that
kicks in: whoever touched it last owns the next problem (which can make it
frustratingly hard to escape), or perhaps the person is given to the least
powerful person (often with the instructions, "just make it work").
This model seems very common in maintenance organizations.
One Owner Per Class (or Package) ("Monogamy")
This approach is very common in new development: the author owns the code
they write, until somebody explicitly takes it over.
The key is that there's a well-defined person in charge of a section of code.
If you want it changed, you negotiate with them. They may even let you change it
yourself, but they'll retain approval rights on what you do. (Sometimes the
ownership will go stale: the person who did one piece is gone, and it's not
actively changing, so there won't be a real owner until someone needs something
done, so the team will assign an owner at that time.)
The benefit of this approach is that it provides a well-defined method for
deciding who does what work, and it lets a person develop expertise in a
There are downsides, though. If the owner isn't available to make a change
when needed, the team is slowed down. (Some teams mitigate this by having
emergency backups.) Sometimes the owner won't agree with a proposed change,
perhaps completely vetoing it. Then clients may design around it or wrapper it
in a way that is worse for the system overall. Another problem is that a single
owner can be in trouble and hide the fact. (The code may be deeply in trouble by
the time their lack of expertise is noticed.)
The single-owner approach can require that interfaces be frozen too early,
before they're really understood, because of the need to let clients "make
progress". Refactoring can be more difficult; when interfaces are public and
require a lot of cooperation to change, there's pressure not to change them for
Musical Chairs ("Rental Property")
Some groups will have a single owner for a package at any given time, but
that owner will be decided on a task-by-task or iteration-by-iteration basis.
This can be good in that it gives people variety, but they may not get a
chance to build deep enough expertise to be particularly effective. Since
there's an owner, everybody knows who to talk to.
The biggest problem is that the code is like rental property: the current
"owner" is really a "tenant"; they know the situation is temporary, so they have
less incentive to worry about the long-term value of the place (provided they
can get out of their lease before it gets too bad).
Ownership by Layer ("Tribalism")
Some groups organize their software into distinct layers, or even distinct
applications, and have ownership at that level. Anybody in the tribe can make
any change they need to - but they keep the tribe informed about what they're
doing. However, nobody from another layer would dare to jump in. (You see this
with user interface vs. business logic vs. database, or app1 vs. app2 vs.
This method overcomes some flaws of "monogamy": the "bus number" is higher,
there's no chance bad code will be hidden from the sub-team, etc. The subteams
can develop a very strong esprit de corps, which further boosts their
However, interfaces between layers are elevated to near "golden"
status, making them even harder to change. This interferes with refactoring
intended to improve the overall system design.
Communication within the subteam is usually good, but it's harder to talk
across layers. A change that requires convincing on person in the "one owner"
model now requires "How about our subteams meet and discuss this - are you all
open next week?" This slows down the team as whole.
Collective Code Ownership ("Everybody")
In collective ownership, the whole team owns all code. Anybody can change any
part they need to.
The key benefit of this approach is that it is the least obstructive to
getting things done quickly. The ability to refactor is improved, as there are
fewer published interfaces. For the right team, this can be an effective mode.
(See the next section, which describes how XP tries to retain its benefits
without falling victim to its risks.)
There are downsides as well:
- Some people take personal pride in their code, and don't want others to
- You risk the tragedy of the commons: "everybody is responsible" can come
to mean "nobody is responsible".
- This resembles "musical chairs" carried even further, perhaps aggravating
the risk that nobody will be expert enough, and that nobody will care for the
- It can be hard to read and work with someone else's code. You may get a
mish-mash of styles and approaches.
- People may step on each others' toes more, as they need access to the same
XP Uses Collective Code Ownership
Extreme Programming recognizes the risks in collective code ownership, but
uses it anyway. XP's practices attempt to mitigate these risks:
- Personal pride: XP doesn't really address this, other than perhaps
encouraging a shift to pride at the team level.
- "Tragedy of the Commons": Pair programming helps ensure that no person can
"pollute" in secrecy. The shuffling in pairs helps make all code even more
visible to the team. Refactoring can clean up any trouble that does occur.
- Not enough expertise: Pair programming spreads knowledge through the team.
The Open Workspace gives others a chance to speak up when one pair seems stuck
or worried. Simple design can require less "deep" expertise. Finally, tests
help ensure that functionality won't diverge from the requirements.
- Reading others' code: A coding standard helps reduce this problem, as does
the shared culture that pair programming engenders.
- Stepping on toes: Continuous integration ensures that people won't go far
without rejoining the main line. The tests ensure that there is no regression.
Conclusion - Code Ownership Models
We've described several code ownership models:
- Last One Who Touched It
- Whoever's Newest
- One Owner Per Class/Package
- Musical Chairs
- Ownership by Layer
- Collective Code Ownership
Finally, we talked briefly about how some of the practices in XP can overcome
the problems that might otherwise be caused by collective code ownership.
Just before delivery
The groups I've worked with have typically had developers working in private
areas, picking up what they need from others as they need it. Before delivery,
there's an attempt to do a "code freeze" (usually called "code slush" at this
point): everybody makes sure everything is checked in, and they resolve any
conflicts due to changing interfaces (especially those that obviously break the
compile). (This is similar to annealing in metallurgy: at first there's a lot of
activity, and as the temperature is lowered, everything settles into a low
The big problem with this approach is that it lets people go off in
drastically wrong directions, with nothing forcing them to test (or even
integrate) for days or weeks. The integration process becomes a lot of work for
whoever must resolve all the problems.
A way forward is to go to daily builds. Every night, the system is compiled,
and a small test ("smoke test") is run.
The developer's motto becomes "Don't break the build". Deverlopers are
supposed to do their own integration testing as they check in, so there should
be no surprises. (The groups I've been in with this process had a project
manager who actively checked that people were checking in as they finished
Groups evolve different mechanisms to deal with this volume. I've heard of
groups that say "Whoever breaks the build must be in by 8 each day to check the
latest build (until somebody new breaks it)." A group I was in relied on peer
pressure by publicizing who broke it. Eventually they got a configuration
management person who had a set start time each day, and whose first
responsibility of the day was to identify any compilation or integration
problems, and get the relevant programmer(s) to fix it.
Continuous integration, as in XP, is not literally continuous, but it does
occur several times per day. Each time a developer (i.e., pair) finishes a work
session, they integrate what they have done. Typically, there's a single machine
for the team's integration efforts, so it's serialized "first-come,
The other aspect of integration in XP is that it is supported by tests.
Developers must keep the unit tests integrated at 100%. To integrate, they take
their code to a machine also running at 100%. After they've integrated: if the
tests are still at 100%, they're done. If not, only one thing has changed: the
code they introduced. They're then obligated to fix the code (perhaps with help
from others), or back out the changes and throw it away. They're not
permitted to leave the integration system in a deteriorated state.
Continous integration is possible in XP because of the "togetherness" of the
group, because it's supported by tests, and because XP provides for simpler
design via refactoring.
Geographically Separate (Including Telecommuting)
Geographically separate groups are based in different locations, and face the
communication difficulties that implies. For example, there may be differences
in language (in the worst case) and differences in time zone. Even groups in the
same time zone can evolve different hours: I worked with a group where one site
tended to get in between 8:30 and 9:00, and the other group around 10-10:30.
With varying lunch and departure schedules, the core hours were 10:30-11:30 and
Communication problems can make this approach more costly, even though it
appears cheaper on the surface. ("We can hire the best people from both
locations.", "We'll put another site where it's cheaper to hire.") There are
travel costs as well as communication costs (including resentment from those who
travel). Most groups must co-locate once in a while. (I know of an international
group that felt that things fell apart if they didn't meet at least quarterly.)
(Telecommuting takes the case of separate workspaces to the extreme, breeding
more communication difficulty, more isolation, and a perception of less
opportunity for advancement. If tasks can be split in a way to minimize the need
for communication, telecommuting may be a welcome approach. I haven't known any
developers to stick with it for more than a year or so, though.)
Offices (1- or 2-Person)
Offices offer the greatest level of privacy and quiet to the developer. In
Peopleware, deMarco and Lister reported that those with offices did the best
in their "coding wars", which they attributed to the need for programmers to
reach a state of "flow".
Offices are apparently the most expensive choice, because few companies seem
willing to provide them for developers. (I'll admit that I've felt most
productive in a 2-person office, though I haven't used an "open workspace" as a
member of an XP team.)
"Cubes" seem to be the form of office least liked by developers and most
liked by the managers who put them there.
Companies I've worked with seem to be making them smaller: 10 years ago, the
standard size was 100 square feet (including for the president of the company);
today (at a different company), the standard is 54 square feet. (And I'm bigger
than I was then!) My current office doesn't allow for two people at the desk,
and even if it did, the computer doesn't fit anywhere but the corner. (Cubes
also seem to be getting smaller and never bigger. A friend at a different
company would have "moving weekend", where you'd pack up your stuff, and end up
in the same office only 6" smaller. By gaining 6" per cube across a
football-field-sized room, they could add more offices.)
Cubes don't allow much privacy or quiet, but they still interfere with with
communication. (I've seen wall heights anywhere from 4 to 8 feet, but they
always seem to be open on top and never have a door.)
XP specifies an open workspace, perhaps with small private spaces around the
central area. The fast machines are in the center, for pairing. It strives for
the mental state where you can focus on your problem, but still hear enough to
jump in if someone needs your help.
The same physical structure without an XP focus can degenerate into a
"bullpen": you're all stuffed into the same space (with no private space). You
aren't on the same project or phase, so the rhythms of your communication clash
with those of others. (This has been the worst office type I've been in (the
pure bullpen, not the XP open workspace.)
I've seen groups starting toward XP also take smaller steps toward open
workspace, by arranging for pairing machines in a spare niche, or treating a
wing of cubes as a public area.
Failing to meet the goal of having small releases is the biggest mistake I've
made in developing systems. When I focus on this goal, I find that "small" can
be even smaller than I would have thought.
I've resolved to start every project with this question: "Will this interface
work?" (Mimic pushing the button with your nose or forehead.)
The answer is often "yes, if you knew these parameters". In that case we
start without a GUI. Where it's not enough, it can get us focused on
understanding what is the minimal useful system. (I've also found that it
can be the developers who resist starting small; I think they have the vision of
what it could be and hate to back off from there.)
Someone in the first XP immersion class (and I apologize because I forget
who) described their practice of producing a ZFR ("ziffer") - Zero Feature
Release. It was an end-to-end release that did nothing, but it established the
architecture and the deployment strategy. It's hard to get a system into
production the first time; updating it is usually a lot easier.
A coding standard is a tool that improves people's ability to read each
other's code. In XP, it supports refactoring as well: consistently "shaped" code
can be refactored more confidently.
There are several approaches to a team's coding standard:
- None. Ugh.
- Each chooses their own and uses it everywhere. ("Then I can tell
where I added code.") Ugh again.
- Each chooses their own for their code, but uses existing style on
existing code. This is the minimum I can live with. Many times I've worked
with a team that intended to have a standard, but evolved toward this as there
was no "enforcement" pressure. At least with this, you can read an individual
module. This approach does interfere with refactoring: when you move code
between modules, now you have to reformat it as well.
- Team has a style and sticks to it. This is the ideal for XP. Since
XP practices collective code ownership, it makes sense as well.
I've seen two group styles in determining this. The first type group has a
huge battle at the beginning of the project with heated arguments over spaces
and braces, but converges on a group style. The second group has no fight, but
builds no group ethic either; they end up with "whatever's right for the code
you're in". I'm not sure how to lead the second type along.
What coding style should be used? In the most recent project where I
participated in defining this (for Java) we had a 6-page summary of
Sun's Java coding
conventions extended with the
conventions. I believe we could probably get it down to a page of annotated
code just as effectively. Perhaps even the page wouldn't be needed with the peer
pressure of constant pairing and refactoring.
We've discussed several practices of XP, and some of the alternative choices
- Code Ownership: Who can change an object that needs to change? XP
says "collective code ownership". If a team is not XP, this may well be
- Integration: How and when does a team ensure everybody's code works
together? XP says "continuous integration". If a team is not XP, I believe
they should still strive toward as frequent an integration as possible.
- Workspace: How should a team be physically arranged? XP says "open
workspace." If a team is not XP, I favor offices, but with attention to the
team's communication paths.
- Release Schedule: How often should a team release their product? XP
says "small releases". If a team is not XP, I think this is still a useful
target, but probably harder for them to hit.
- Coding Standard: How should the code be written? XP says "team must
share a standard". If a team is not XP, I think a team standard is still