Social factors and software architecture

Somewhere I found a reference to a paper titled On the Interaction of Social Issues and Software Architecture written by Alistair Cockburn (see here for a post about another article of his). He writes about how social factors affects software architecture and if I ever write a book about about software architecture, I must say something about this.

I have never thought of it before, and yet it is so obvious. Not that obvious in an Extreme Programming context, though, where you don’t explicitly partition the team by skill and assign ownership of subsystems based on that skill. But recently (and especially while reading this paper) I’ve been thinking that in some cases, you might want to consider to assign ownership based on skill. I can think of projects where people would want to work with things they feel comfortable in. And even if you don’t assign ownership, such people will probably accept responsibility for the same types of things, so that you in effect get a team that is organized by skill anyway.

Cockburn captures in pattern form six principles: Variation Behind Interface, Subsystem By Skill, Owner Per Deliverable, Subclass Per Team, User Interface Outside and Facade. Each of these principles are derived from an external force and balanced by a counter force. For example for the Owner Per Deliverable principle, the force is that “people get confused if ownership is unclear” and the counterforce is that “too many owners and too many deliverables make for a heavy bureaucratic load”.

From these principles design decisions are made, which he also captures in pattern form. For example, the Three Subsystems design decision is derived from the Subsystem By Skill principle and identifies three subsystems with one sub-team for each. Then he describes eight more design decisions.

In the beginning of the paper, he refers to M. E. Conway who in 1968 wrote something that can be summarized as “Architecture Follows Organization”. In 1995 James Coplien presented a pattern called “Organizaton Follows Architecture”. Both these are true: if you would create an architecture not knowing about the team which will implement it, that team would organize itself around the architecture. Cockburn’s paper shows that it might be wise to consider the social factors when thinking about the architecture.

One social factor I can think of immediately is one I have thought of in my work with Burger, the blog tool I have written. Very soon after I began I started to get suggestions for features. Some of them I liked and some of them I could see the need for, while not wanting to use it myself. Jonas wrote some code to generate a MovableType style calendar, for example. This is something I know people will want, but I don’t want one myself and since Jonas seems happy to work on it, I thought that things like these should be able to plug in into Burger.

This decision is an architectural one. I’m making it a plug-in architecture so that people can code whatever they want and use it with Burger, and I don’t have to think about it. I’m very picky about the coding style and design and I find it difficult to communicate those ideals to people who want to contribute. I also realize that my standards are way too high, but I like to keep things clean. An architecture like this lets me think less about trying to either convince people to write code in my style, or to take their code and rewrite it. Both things are very rude to do and I want Burger to be an open project, so the open architecture is excellent.

The above was posted to my personal weblog on August 2, 2002. My name is Peter Lindberg and I am a thirtysomething software developer and dad living in Stockholm, Sweden. Here, you’ll find posts in English and Swedish about whatever happens to interest me for the moment.


Related posts:

Posted around the same time:

The seven most recent posts:

  1. Tesugen Replaced (October 7)
  2. My Year of MacBook Troubles (May 16)
  3. Tesugen Turns Five (March 21)
  4. Gustaf Nordenskiöld om keramik kontra kläddesign (December 10, 2006)
  5. Se till att ha två buffertar för oförutsedda utgifter (October 30, 2006)
  6. Bra tips för den som vill börja fondspara (October 7, 2006)
  7. Light-Hearted Parenting Tips (September 16, 2006)