This weekend, I’ve been working on my presentation for acts_as_conference. I’m talking about best practices for working on a Rails team. I’m not approaching this as if I were the final authority on how to program Rails; instead, I’ll be offering up some examples of problems I’ve seen and ways of dealing with them.
At a higher level, I want to talk about working together on an effective software team. In order to do that, I’m re-reading some of my favorite books about programming: Code Complete, The Mythical Man-Month, Patterns of Software (download), Peopleware and others.
This research has made me somewhat re-think my thesis, which focuses on what we can do to improve Rails teams’ productivity. What I’ve realized is that much of this is out of the programmers’ hands; and also that “productivity” is something of a biased term. In “Productivity: Is there a Silver Bullet?” Richard Gabriel writes:
The word productivity itself is somewhat loaded. Do programmers working at some company wish they were more “productive”? Probably not. Such programmers wish they were more effective, that their tools were better, that there were fewer barriers to getting work done, that management was more competent, that working conditions were better, that there was some direct link between the success of that company and the efforts of the programmers, and that it wasn’t a struggle for the company to survive from quarter to quarter. Productive is a term used describe what an employee is or isn’t.
The essay goes on to argue that to a large degree, developer productivity is not based on technology, but the programmers’ environment.
As a programmer, I don’t have a lot of control over that, but we have to acknowledge its impact. Since I’m a programmer, not a manager, my talk will focus on what we, as programmers, can do to work better together.
It gets harder to work on a team the bigger it gets. Look at the exponential quadratic growth of communication channels between developers as a team grows.
By the time we have 6 developers working on a project, there are 15 communication channels and things are starting to get hard to manage (let alone draw in OmniGraffle). And this is a pretty small team!
None of this is news. But what does Rails bring to the picture? By removing a lot of the busy-work associated with older frameworks, it lets fewer programmers get more done, which helps our communications problem. But Rails teams have to overcome some hurtles of their own…
Stay tuned, I’ll be posting more on this subject this week, and I hope some of you will be able to join me in Orlando to discuss this!
The function that computes the communication channels is not exponential. It is quadratic. That is a substantial difference.
@Teacher of Basic Maths
Ah, language. Even when you’re right, Luke doesn’t necessarily have to be wrong. Popular usage does some funny things to your beloved mathematical terminology.
http://dictionary.reference.com/browse/exponential%20growth#sharethis
Ah, I stand corrected then.
The formula for communication channels is (n-1)(n)/2 where n is the number of developers, so that is quadratic.
http://en.wikipedia.org/wiki/Exponential_growth
http://en.wikipedia.org/wiki/Quadratic_growth
Hurray for math!
Luke, I am curious about your experience—I have been reading books like Peopleware and Agile Software Development, and they seem to be at odds in a way.
Peopleware seems to promote people having their own office, whereas books like Agile Software Development tends to push having developers all working in the same room.
I guess that’s one aspect of it, but since work environment is so integral to the job, I am wondering what the best way is.
Since I’ve been telecommuting, I’ve been wanting to have actual coworkers to speak with, so perhaps I have swayed more towards favoring having the entire team sitting in the same room.
Tony, good question.
I think the reason why there is so much disagreement about this is because it comes down to personal preference.
I prefer private offices because noise drives me insane while programming. I also don’t like listening to music while programming so headphones are not usually an option. I think the idea of productive cross-talk has something to it, but in my experience the cross-talk is more likely to be something distracting like a cool website or what happened last weekend.
But a lot of agile advocates like shared space. Maybe the noise doesn’t bother them as much? I know the refactr guys just got a new office and they’ve set it up with a mixture of shared and private space (details here).
I think a small team (no more than 4 people) in a single, quiet room would work well. I share my office with one other programmer, and when we’re working on the same thing, it works out well. When we’re on different projects, people coming in to talk to either of us distracts the other.
Cubes are the worst of both worlds. They are noisy and impersonal. Everyone seems to agree with this.