What's this?
I'll put links to readings, plus a few notes, here.
You will usually have a week to read each paper, e.g., a paper may be posted on a Thursday with discussion the following Thursday.
When possible, I will post an ACM digital library link, rather than a direct link to a local copy. There's a reason for this: ACM keeps track of accesses to the digital library, and keeps track of which conferences and journals have high readership. By sending you through the digital library, I'm essentially making sure that your readings are credited appropriately. The authors don't get royalty payments for this, but they may get recognition.
University of Oregon has an institutional subscription to the ACM Digital Library, so you should be able to access these at no charge. If you follow the links from on campus, it should “just work”. From off campus, please follow the directions at http://libweb.uoregon.edu/systems/proxy/ to gain access.
Reading 1: Herbsleb & Grinter
Herbsleb, J. D. and Grinter, R. E. 1999. Splitting the organization and integrating the code: Conway's law revisited. In Proceedings of the 21st international Conference on Software Engineering (Los Angeles, California, United States, May 16 - 22, 1999). International Conference on Software Engineering. IEEE Computer Society Press, Los Alamitos, CA, 85-95.
Notes
Some things to look for and think about when you read.
Conway's Law
The original article by Conway has been hard to find, and until recently I was not aware of an electronic version. Now there is one: How do Committees Invent by Melvin Conway, reprinted from the original 1968 article in Datamation magazine. It is not required for this class, but it is worth reading, despite its age (40 years old!).
The short statement of the law is:
Any organization that designs a system (defined more broadly
here than just information systems) will inevitably produce a
design whose structure is a copy of the organization's
communication structure.
Consider also the converse: You can design an organization to
be a good fit for the product it is constructing. Company's
do this, or try to do this, all the time. Consider Intel's
recent reorganization (see the CNET article on
Intel's
2005 reorg) aimed at improving communication along
“platform” (application domain) lines (channel
products, digital health,
etc) rather than along lines of products like flash memory and
processors. One could argue whether this is the right
organization, but Conway's law suggests it will have definite
consequences on the products Intel produces. You can see
similar issues of modular organization in many other
industries. And you can see it in the University, where the
structure of the institution impinges on education and
research (and vice versa).
Brooks' Law
Adding more people to a late project makes it later. Why?
Unplanned communication is essential
Herbsleb and Grinter put it this way:
What appear to be merely “casual conversations around
the water cooler” often serve to informally exchange
the kinds of information and experience that are critical to
project coordination.
It's important to make
opportunities for people to discover that they have
something to talk about. This is a major challenge not only
for the sort of distributed project teams that Herbsleb and
Grinter describe, but for any project organization that does
not bring participants face-to-face on a regular, informal
basis (e.g., organizations in which telecommuting is the
norm). And it's one reason I think conventional,
face-to-face classes are usually superior to distributed,
computer-delivered classes.
Culture matters
Software development is increasingly a global enterprise, and probably some time in your career you will be teamed with people with a different cultural background. As the case study in this paper illustrates, cultural differences (even just between Germany and Britain, two European countries) can lead to important misunderstandings. Learning to work well across cultures is increasingly important.
The paper also talks about differeing “engineering cultures”. Another term you'll hear is “corporate culture”, and there are even industrial anthropologists that study corporate cultures using methods of cultural anthropology. Informal communication is important to bridging all sorts of cultural gaps. So is making a conscious effort to understand more about the culture of the people you are working with.
Actual process vs documented process
Don't believe everything you read. How people actually get their work done is seldom quite the way their bosses believe they do it. There is a corollary for designing any system that automates some human process (e.g., if you were replacing a manual, paper-based purchase requisition process with a system for making purchase requests online): You must, must, must talk to the people who really perform the process you are automating. Listen politely to their bosses, then insist on some time alone with the people who really do the work, and ask them what they really do.
Multi-site development
Herbsleb and Grinter end with some advice for reducing the need for inter-site communication and overcoming barriers to informal communication. These are good suggestions, but also think more generally about the general principles and other steps you might take depending on circumstances. For example, what can we infer about differences in needs between building a system in a very familiar application domain (that is, familiar to our particular organization) and developing a system in a domain that is very new to us, or using a very different approach?