Matt Heusser’s Blog
Testing at the Edge of Chaos
February ST&Pedia is out!
Hey hey, I got copies of the newest issue yesterday.
You can download the February ST&P here. The magazine remains free, though you may have to register to STPCollaborative. This month Chris and I cover communication channels for massively distributed(*) development. Here’s the introduction:
When Matt was in graduate school, he nearly published a paper called “On the Optimization of Physically Distributed Development, Test and Requirements Staff.” The body of the paper was shorter than the title, and consisted of the words “That trick never works.”
About ten years ago the software development community began to realize that communication among people on large or distributed teams was expensive. To minimize that expense, development organizations attempted to minimize the amount of communication at each step in the development process. Inspections, handoffs and formalized sign-off procedures were considered “best practice”; Matt took one class with a 600-page book describing how to do it in some detail. Today, he uses that book as a doorstop …”
Some errata: Actually, the books been all over. It spent five years or in the attic; I may have used it for my power strip to “stand on” so that the cable to the powered bunny ears for our TV wouldn’t be too tight. Then TV went digital.
I am certain I have used it to straighten out old papers and posters that have been warped. It’s nice and heavy.
Also, arguably, we’ve known that communications on large teams are slow for a loooong time; Fred Brooks defined this in Mythical Man-Month in the middle nineteen seventies. Perhaps “realized” isn’t exactly the right choice of words, but the theory that the “fix” for distributed dev was to “get it right” the first time and prevent the distributed teams from actually talking to each other was certainly en vogue by the time I was in grad school.
Ten years after I took those graduate classes in IS Theory, I am pleased to say that I was wrong. The current team I work at Socialtext is more high performance than any others I’ve worked on — and some of the team members (Dan Bricklin wrote our spreadsheet), simply would not have been willing to move at any economical price. Yes, I’m sure if we took the whole company budget, we might have got Dan to move from Boston, but there would be no money left over to get me to move from Michigan, or Audrey Tang to move from Taiwan.
In other words, it’s not really possible to compare certain types of physically distributed teams with on-site, because you can’t get the same talent of people on-site. Oh, sure, you can get some pretty good testers, but it’s hard to get the guy who invented the spreadsheet, or the lead committee of the haskell project. And yes, the hippest trend with devs today is to try to learn Haskell; Audrey is the leading the effort to write the Haskell compiler.
And yes, I have experienced a team that used modern tools to make the communication environment feel at least as good, it not better, than other on-site environments I’ve worked in. Chris and I wrote an article about, it begins on page eight.
(*) – By “massively distributed” I do not mean three to ten different teams, each commuting to a small office, each tasked with a different piece of the software. I mean one team, where the members do not commute at all, that can work from anywhere with electrical power and high-speed internets.
To quote John Lennon “You may say I’m a dreamer … but I’m not the only one …”
Comments (1)
at February 9, 2010, 12:32 am:
Cool blog! It’s neat to see distributed teams really working well.
The first time I did the collaborative test events across time zones I thought “What crap! This will never work.”
The third time I was shocked that it DID and DOES work. It takes some adjustment and it just isn’t “the same” as working in one location. It can be great though! I think that the goal has to be to make it great and give up on the idea that great means “the same as being in one location”. There are challenges and advantages to working on a distributed team. I like the idea of just getting over the expectations and bias and moving on to what works for the team in practice.