Reading the first few books in the XP Series clarified
so many thoughts in my head that I started keeping a
journal of XP-related ideas (Justin's Extreme
Journal). Here is an early entry:

'''The Code Looks Like the Team''' 7/27/01

Considering the responsibilities of our teams, we have
tried to promote an impermeable opaque interface layer
between the work of [my team] and that of [another
team]. Concerns have been raised that this is an
arbitrary division, and that design decisions
shouldn't be forced according to "who's supposed to
work on what code." Indeed, XP tends to favor free
roam of all programmers over all code in their
product. EricRaymond noted that there is a truism
that the organization of a system tends to reflect the
organization of the people who design it. He brought
that up in order to make a positive comment about OpenSource
development -- developers working independently
communicating through the network tend to produce
systems with independent modules communicating in
similar patterns. For another perspective, consider
that FredBrooks initially advocated a completely open
development environment [in "The Mythical Man-Month"],
but later decided that an "information-hiding"
approach is more effective [in the revised edition of
the same book].

Let's consider turning around the "code reflects team"
idea. The connotation is generally that the code
organization ''follows'' the team organization, but what
if instead the team organization follows the code
organization? In the former case, a concern comes to
mind that the code may be artificially constrained
according to an arbitrary team organization. In the
latter case, however, an intriguing possibility for
team organization comes to light. If the team is
organized according to naturally occurring stable
interfaces in the code, then future development is not
unduly constrained. Indeed, splitting teams with
well-defined interfaces may be essential for
development of very large systems. XP teams are
supposed to be 3-10 people for best effect. This
suggests that, while any product should ''start'' with a
single team, if that team grows large it should split
into multiple teams -- with some teams as "customers"
of others. This requires stable, impermeable
interfaces between the teams to prevent interference.
Team splits will be suggested by refactoring trends.

This seems to be precisely the genesis of [my team].
Trends in refactoring have long been pushing
functionality into [one particular component]. This
suggested a natural split along this feature-oriented
layer, with [another team] as the customer of [my
team's] product.

-- JustinSampson
----
When I posted this to the ExtremeProgramming Yahoo!
eGroup, MikeBeedle pointed out that this is ConwaysLaw.

I must have read this law in EricRaymond's "TheCathedralAndTheBazaar" but for some reason I didn't
remember the attribution. I just looked again and
Raymond does call it Conway's Law in an end-note.

He also gives another version: "If you have four
groups working on a compiler, you'll get a 4-pass
compiler."
----
The question I was trying to answer at the time was
this: Should everyone in the company have collective
ownership over all the code in the company?

We weren't doing XP anyway; we were just started to be
influenced by XP ideas. Now I expect if we had
been really doing XP we would have been able to handle the whole system
without breaking down the teams. As it was I was getting
frustrated with others coming in and making changes to the
code my team was responsible for without following our
coding conventions or pairing with us.

MichaelFeathers commented in another message on the XP
mailing list that he'd seen an XP team that worked fine with
dozens of people, and even tried to split into multiple
teams and didn't like it. And he said he's seen other teams
that just couldn't handle being larger. So it's all about
the people, as XP always stresses...