RISE FROM THE GRAVE!Anyway, I find that my most productive work happens in a PP-like environment. Two people to two computers is still the best way to go about it, but park their asses right next to each other. This makes for excellent division of labor for tasks that can be paralleled (one guy prods the UI, another prods the database, and whoever finishes first prods the data access layer, shit like that) and gives a second set of eyes for actual hard problems. It's also my experience that having an extra 10% (one dev per 5 teams) makes a dramatic difference, especially if that extra man is the most experienced. That extra developer is an excellent supervisor (assuming that in addition to being the most experienced, he's also not a prick hung up on 'his way') - feeding and nurturing the teams under his command, delegating to them the work that is the best suited to them, shoulder surfing and giving advice, maintaining documentation (which as a rule should not be more than 10% of his time - I mean really basic essential documentation - architecture diagrams, database diagrams, the kind of information that you stick up on the wall of the office for a quick reference), working as a third developer on a team to get more parallel threads for a critical issue, and giving a third, more experienced set of eyes for really stubborn problem. He's also a great first step for code reviews. Experience shows that with a full team of 11 'paired' developers, you wind up with about 225% productivity versus 11 independent developers (since they're both working on a task, and are depending on each other, they won't tend to facebook the day away - and the extra man prevents them from making a secret facebook pact - unless you make the error of making that extra developer LITERALLY be their boss, instead of being another peer with only informal management abilities) and a large measure of improved code quality. Strict agilista pair programming sucks ass, though. Two heads, one computer? Double the cost for 150% productivity and 125% quality. I was part of an agile transition once, and several (new, freshly educated) developers were advocating following such and such agile methodology to the letter - it took me getting up in front of everybody and reminding people that the whole fucking point of agile techniques is to be able to target the development team to the crack-addled herd of cats that are business requirements, all the while getting it done faster and better. A particular 'agile vendor' comes up with something that worked once and sells it.You can either take their word for it or play with it - combine it with other techniques, tweak things in ways that sound like they'd make for a better working environment AND more productivity ("Really guys. Do you want to not have a computer to call your own?" works nicely) and if it doesn't work, change the damned processSo we ended up with a mashup of eXtreme Programming, Scrum, RAD, and dozens of other nauseatingly boring (but edgy-sounding) terminologies for simple, logical ideas that follow from these. And. It. Fucking. WORKED. I could make a bazillion dollars on the Agilista lecture circuit if I cared more about money than I did about enjoying myself.
