The folly of large teams

I came across this post on "The mythical man-month" (referring to a unit of labour) through twitter (via @finiteattention) and it really hit home. There has been a lot of complaining and hand-wringing and head-banging about the ECHOES project having grown completely out of control in a number of ways, and though self-labelled hacker-at-large Dhanji R. Prasanna wrote this post about a Google effort, it could easily have been written about all of us on ECHOES (except for the part about massive server traffic). For added fun, ECHOES also had the issue of the workers being physically in many different locations!

I would like to quote a few especially pertinent passages here:

"First, there was the dreaded endless meeting--they lasted for hours with very little being decided. Then, you started having to push people to provide...code changes that you desperately needed for your feature but that they had little to no interest in beyond the academic.
My style is to ask politely and then when I realize nothing is going to be done, to do it myself. This...does NOT work in large teams. There is simply too much system complexity for this to scale as a solution. Instead of shaving one Yak, you're shaving the entire Yak pen at the Zoo, and pretty soon traveling to Tibet to shave foreign Yaks you've never seen before and whose barbering you know little about."

So true. I'm laughing at that to keep from crying about it! Or how about this next quote? Replace "programmer" and "hacker" with "researcher"   and you definitely have ECHOES again.

"And this is the essential broader point--as a programmer you must have a series of wins, every single day. It is the Deus Ex Machina of hacker success. It is what makes you eager for the next feature, and the next after that. And a large team is poison to small wins. The nature of large teams is such that even when you do have wins, they come after long, tiresome and disproportionately many hurdles. And this takes all the wind out of them. Often when I shipped a feature it felt more like relief than euphoria."

I agree with the author that that really IS the key point about large teams-- they kill enthusiasm. It is impossible to congratulate yourself or your colleagues about any success because it took so miserably long to get there (and has likely created a wealthy of bad feeling and OTHER problems along the way). A success doesn't feel like a success any more. ON a bad day, I find it doesn't even feel like it was worth the effort to get there at all. Researchers and other people working in teams talk about "project politics" for a reason. There is not just because of the interpersonal issues that often get the label of being politics, but also the sense of protracted negotiations, constant friction, and people fighting their own disciplinary corner to the extent that they may lose sight of broader objectives.


When mini-teams are constantly barking "Fix this now! Turn attention level up to 11!" at other mini-teams, it seriously wears people down. Like in the human body, existing in a state of constant emergency contributes to the emergence of stress-related diseases (See Robert Sapolsky's excellent and entertaining book Why Zebras Don't Get Ulcers). For large teams, this takes the form of constricted communication channels, attacks of angry rhetoric, and dampened enthusiasm.


All of that said.... the author is also right when he writes of the potent blend of frustration and passion that makes such a team and project compelling and unforgettable. It's true, I totally get it. You look back fondly at the complete madness and the colleagues upon whom you wished painful deaths as you slaved away late at night, trying to fix problems and finish documents. I don't know why this should be so, as it seems like a completely insane and unreasonable way to feel about anything that has caused so much stress (for everyone!). Maybe it is some kind of cognitive dissonance reduction strategy? On the other hand, maybe it's not, I have used that term incorrectly, and Leon Festinger is now rolling over in his grave.

Upcoming events: September-October 2011

I'm going to be attending all kinds of exciting stuff this fall semester! Even though I'm not officially in school (Uni, whatever), I can still work on getting edumacated. This is not to say that I don't learn anything the rest of the time-- I read academic papers and reference books for work just about every week, and have the highly illuminating the hands-on experiences of working with children + technology, and playing project politics.

Tomorrow, September 8th: SCERTS framework follow-up day 
(University of Birmingham)
 I am a big fan of the SCERTS framework for autism intervention, having gone to the big three-day training session last September with one of the SCERTS founders and authors, Emily Rubin, and then having used elements of SCERTS within the ECHOES project. Emily Rubin will also be leading this day, with many of the same attendees from last time. The goal is for people to present examples of using SCERTS in practice and to get feedback. ECHOES has submitted some video/written material for Emily to view and comment on later, at the end of the day. I am a bit nervous, as she will look at the ECHOES video coding scheme (which we have based on the assessment process and behavioural goals in SCERTS). As I have written almost the entirety of that document, I feel like I am somewhat on the line here-- I really hope she approves!

A few words describing SCERTS, excerpted from my intro to the video coding document:

SCERTS is most accurately called a framework rather than an intervention programme in its own right, because it is compatible with a range of other approaches and interventions already in use with people on the autism spectrum, such as TEACCH (Schopler & Mesibov, 1995), the Picture Exchange Communication System (PECS, Bondy & Frost 1994), and many others.

SCERTS stands for Social Communication, Emotional Regulation, and Transactional support, the three main areas on which it focuses for helping children to achieve social and communicative competence, and for helping social partners (e.g. teachers, parents, peers) to support the child in achieving this competence. The SCERTS curriculum targets the “core deficits” of autism which are usually an impediment to social and communicative competence by setting specific, developmentally appropriate goals. These may be both educational goals, and identifying transactional supports (changes to child’s environment, and to social partners’ interactions) which help the child to achieve the target goals. For a summary of some of the main goals/targeted areas in the SCERTS framework, see Table 1, reproduced from a paper by Prizant, Wetherby, Rubin, and Laurent (2003). The curriculum is designed to be administered by a team across all of the child’s usual settings—not only the child’s teacher and other school staff, but family members and even peers. The entire team ideally uses the same methods for supporting and communicating with the child, and is aware of that child’s behavioural goals and progress toward them.

Friday, September 9th: One-day conference on Autism Education
(University of Birmingham)
From the official conference materials: "This conference on autism and education brings together leading experts from the UK and the USA who will present some of the latest developments in education research and practice. The particular focus of this event will be to showcase and discuss some of the critical ways in which children with autism can be assessed in school settings and how these assessments of progress can be related to meaningful targets, particularly for adult life."

I am hoping to further inform one of my still-nebulous PhD project ideas. Specifically, finding out about good resources and strategies for embedding technology and other intervention programmes into classroom practice. "Embedding" technology in educational practice is a current big topic in the AIED (artificial intelligence in education) community, partly because it has been realised that the most successful project are those which are embedded, and also because that community is becoming savvier to what the education research people have known all along: teachers are an invaluable research resource in terms of contributing to what you build, and how, not just what to do with it now it's finished. Anyway, I digress.

October 12th, SICSA Workshop for Technology on Health & Wellbeing
Glasgow Caledonian University
I don't know as much about this event as yet, but I will say that I am not presenting anything, and I don't think anyone else from ECHOES will be either. However, it still  might be useful/informative to me so I am happy to go along and be the attentive audience! Health technology seems like it will be increasingly important in the future, especially as the population ages. I also think it is likely to mutate significantly, along with other changes in the fields of pervasive, ubiquitous and mobile computing in increasingly "smart" environments. 

Why start a research blog?

It’s good practice to keep a research journal, as an aide-memoire to later writing up of whatever you are doing now and to prevent too many good ideas and connections from disappearing into oblivion. I have plenty of notebooks, and there is a post-it note stuck to every flat surface in each of my various working habitats. I am starting this blog for an additional but equally important reason: the results of scientific research have enormous cumulative impact on the lives of everyday people, but there is relatively little understanding of where those results come from and who does the work.

By “where” I mean both established methods of collecting and testing knowledge, and the slow process of wrestling with a problem or building a potential solution over months or years. On a more basic level, there is also the question of why particular questions are being asked in the first place. In this outlet, I am planning to write about process. I personally think that in many cases it is as valuable or even more valuable than the neatly reportable end results. It’s the old case of teaching a man to fish versus taking him round to the chippie and buying him a fish supper.

I freely admit that I have some solid experience in a fairly narrow area, and some reasonable level of knowledge surrounding that. Career-wise, I am at the beginning. I am currently employed full-time as a researcher, and start my PhD in a little less than 6 months. I am inviting the blog-reading public along for the ride. Hopefully you can find out something interesting from me, and I can find out something interesting from you.