So, Apparently, Teamwork is Counterproductive…

Teamwork is not easy.  It never is.  Whether it’s basketball, football, sales, construction, or software, it’s difficult to instill a sense of team and ensure that everyone operates as a member of a team.

There are individual egos to deal with, different levels of skill to integrate, different talents that have to be recognized in the context of the team, and there is the ever present problem of communication.

Lately, I’ve been disappointed in the level of teamwork I’ve been witnessing on my project (on a scale of 1-10, it’d be around a 2).  Sure we have our weekly call in and discussion and random emails throughout the week.  But is that enough to bring a large system, with multiple components together in a short timeframe?

I recently suggested to my teammates that we’ve been lacking the team spirit and that perhaps it’s a good idea for those that will be interfacing with my component to at least install and test against the actual component that I wrote.  The following is my response to the response that I received, which claimed that such efforts at this time are “counterproductive” (names have been changed):


Hmm…here I thought we were building interacting pieces 😉

I don’t know, maybe it’s just me, but I feel like one person can only take code so far; working in isolation with little feedback leads to code with obvious bad practices and holes that are hard to spot once I’ve gotten a concept in my head. Not to mention that there will be tons of duplicate work efforts (as I discovered from Brian the other night, the database work I’ve been doing is also relevant for Don and Sam). I’m 100% certain that there will be bugs and inefficiencies that will only be turned up once you and Sam start to interface with it. Not only in my code, but also in your codebases as well. At least from my perspective, I’d like to find these bugs and hammer them out. To hope for the best when we plug it all together at the last moment is a bad way of working, IMO. I would even propose that the Friday session every week be turned into a full integration and end-to-end test session to get everyone to integrate and test pieces with a seperate Monday session to cover what the goals are for the week and catch-up.

And again, my piece is here to service WildCat and RazorBack…how can I be sure that it does this in an easy to use and well designed fashion if I’m the only one using it? It is certainly easy to use and well designed *to me*, but are there obvious mistakes in the design? Are the major flaws in the code that need to be fixed? Who knows? Everything looks rosy *to me*. End-to-end testing has not been done or setup and I feel that there are sure to be issues that will only be uncovered with end-to-end testing. I know there are flaws and I want to fix them, but many of the flaws are not so apparent to my eyes but would easily be exposed by end-to-end testing and WildCat and RazorBack actually integrating with the pieces.

I understand that we each have responsibilities. But isn’t part of my responsibility to ensure that my piece properly services WildCat and RazorBack? Alternatively, isn’t part of WildCat’s responsibility to ensure that it can tell EastCastle to do what it wants?

I feel like the way we’re working is much like a football team which never practices as a unit, each player only works on individual drills. Come game day, now all of a sudden the team is expected to play as a unit. How can the coach predict whether the team will work well if he never sees them practice as a unit? This is unrealistic even for the most skilled professional football players (that’s what training camp and full team non-contact drills are for)…how can it be realistic for us? I dunno…building large systems is no less a team game than basketball or football or crew 😉 : the team that trains together wins together. Expecting pieces to magically work together after weeks or months of development in silos is dangerous and unrealistic to me.

Teamwork is difficult for any group of guys and gals.  Doubly so when the team is dispersed.  But is it “counterproductive” to try to build upon a team effort and really have everyone write software as a team?  Is it really an idealistic view of how software should be written that I’ll discard as I age and become more cynical?  Bear in mind that I’m not debating “Aristocracy, Democracy, and System Design” as Fred Brooks does in Chapter 4 of The Mythical Man Month, as I strongly believe in “conceptual integrity” as a basis for simplifying and clarifying a framework or codebase.  But rather, what I’m questioning is the team working completely independently with little communication and actual testing of interfaces.

I’ll admit that I myself haven’t been the best of team players, but, none-the-less, all I was seeking was a minimum amount of teamwork: integrating pieces once in a while in “practice” as opposed to integrating in the few minutes leading up to game time and hoping for the best, you know?

You may also like...