The Code Looks Like The Team

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