XPlorations

Code Ownership

Nobody ("Orphan")

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 particular area.

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 political reasons.

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. database.)

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 productivity.

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 touch it.
• 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 long-term value.
• 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 objects.

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:

• Nobody
• 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.

Integration

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 energy state.)

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.

Daily Builds

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 tasks.)

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

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, first-served".

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.

Workspaces

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 1:30-4:30.

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.)

Cubicles

"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.)

Open Workspace

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.

Small Releases

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.

Coding Standard

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 JavaBeans naming 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.

Conclusion

We've discussed several practices of XP, and some of the alternative choices possible.

• 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 problematic.
• 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 appropriate.

Resources

• Extreme Programming Explored, by Bill Wake. This article is the basis for chapter 3.
• Extreme Programming Explained: Embrace Change, Kent Beck, 1999.
• Code Ownership: Jim Coplien's pattern for "single owner."
• Code Ownership: Ron Jeffries' writeup on "collective code ownership" in XP.
• Surviving Object-Oriented Projects, Alistair Cockburn, 1998. Discusses various models; recommends "Owner per Deliverable."
• Peopleware, 2/e, DeMarco and Lister, 1999.
• Continuous Integration in XP

[Written 2-15-2000.]

Copyright 1994-2010, William C. Wake - William.Wake@acm.org