Home > Development, Rants > Team Team Team

Team Team Team

October 31st, 2005 Leave a comment Go to comments

About the only thing I liked about double sessions in high school was the “free” t-shirt and shorts that came with the job. Even now, when August rolls around, I can’t help but think about all the kids returning to the gridiron – and I’m thankful that those days are behind me. Don’t get me wrong, I really enjoyed playing ball but I don’t miss doubles. At all. But I will say this in their defense – you really start to appreciate the basics that time of year – things like water, food and shade.

It may seem odd to be talking about late August football in November but I have a point, really, I do. Let’s get back to those t-shirts. Every year, we’d have some team oriented saying printed on a heavyweight grey Champion shirt, you know something like “There’s No I in Team” and “Team Team Team.” Throughout every practice and every meeting, we were constantly reminded that football is a team sport; the team was the only thing that mattered. Maybe it’s this background but I’ve always believed that the people and the team they created was far more important than any scheme, system, or strategy but all I know is I’ve seen teams that on paper shouldn’t win more than a few games go undefeated and those with tremendous talent lose more than they you’d think possible.

It is with this background that I read Glenn Vanderburg’s piece called The Right Team for Rails. While this article is specifically about Rails, I think it applies to *any* language and Glenn even mentions that at the end. This part really speaks to me:

An experienced, skilled team will, in all likelihood, find ways to be successful. An inexperienced one can find many ways to fail. Somewhere in the middle are the teams where each project is a gamble: they might fail, or succeed modestly, or even succeed spectacularly, but it’s very hard to predict the outcome. No tool, language, or framework — not even Rails, which I think is the best thing going — will change that. When you pick up a powerful tool, it doesn’t eliminate your weaknesses; rather, it amplifies whatever characteristics you bring to it, strengths and weaknesses alike.

While I don’t have anything against process or the people that worship at its altar, I often find myself reaching for Alistair Cockburn’s classic piece Characterizing People as Non-Linear, First-Order Components in Software Development – which is just a really fancy way of saying people are more important than process. I just hate it when a coach brags about how he can fit any athlete into “name-your-key-position” because of his superior system (can you say Denny Green?). Of course if that were really all there was to it, wouldn’t everyone adopt the same system? How would head coaches justify their exorbitant salaries?

Of course development mangers are not immune to this virus – typically they are searching for some way to justify why they let the experienced people leave (or why they RIFed them) and process is so often the trump card. Consultants are quick to feed this myth by assuring said managers that they can plug anyone into their spiffy process and low and behold beauty shall result!

Of course it never works that way does it? If it did, would not a room full of monkeys be able to produce the complete works of Shakespeare? By now, shouldn’t we have figured out what the “best” process is for software development and adopted it industry wide? Certainly, if there was a fail-safe way to build software, we’d all use it and we wouldn’t hear about staggering failures like the FBI’s recent fiasco.

If you ask me, team is awfully darn important when it comes to building great software. The right group of people really can work magic – and have a ton of fun doing it. If you’ve ever been a part of a high performing team, you know what I’m talking about. I’ve been there a few times and I think about ways of getting back there regularly. How about you? What is the “right” team when it comes to building truly kick-ass products?

Categories: Development, Rants Tags:
  1. No comments yet.
  1. No trackbacks yet.