20 February 2012

Is your Team LCD (Lowest Common Denominator)?

On some of my previous projects I have felt that the teams became severely dysfunctional and as a result they cater to the lowest common denominator of the team.  This was often a result of a lack of both technical and overall leadership.  In these cases schisms formed in the team I was usually at the center of one side advocating good design practices, a high degree of control and a framework approach to reuse.  I should add here that while I am very passionate about trying to build quality software and I try to be as egoless as possible.  Sadly my opponents in these situations were the type of programmers that did not read and in some cases they were woefully ignorant of basic software design concepts like the Solid principles and design patterns.  In one case we had several “senior” java developers who didn’t understand generics or even inheritance, that situation really bordered on the absurd.

In these situations I have often felt that these developers were essentially being very selfish, in some cases it was that the developers wanted a wild west chaotic approach to software development so there were no constraints and they were free to tinker with new libraries and frameworks, what I like to call Resume Driven Development. In other cases it was that they didn’t want to have to learn anything new or challenging, and in some cases it seemed to be pure ego driven stubbornness or inferiority complex driven compensatory behavior.

Regardless of the causes of the dysfunctional nature of the team it always resulted in the dominance of the Lowest common denominator, this can applies to technical level as well professional/maturity level, often it’s both.  The lack of leadership and a fractured team often had negative effects on morale especially for the better developers.  It often created an environment that produced suboptimal architecture and code.  Consensus was often impossible to achieve and code duplication was rampant sometimes deliberate.  Naturally code reviews were either not conducted or if they were they were done in a perfunctory way so that any feedback was completely disregarded.

The worst part of the LCD team is the lack of ability to have open objective criticism.  Criticism is hard to take but anyone engaging in any activity, especially a creative one, in which they wish to improve can greatly benefit from it, this is described in detail in a great essay by Bobby Grossman.  To parallel that essay we had one person on the team who if you even hinted at being critical he immediately became super defensive.  He was a terrible programmer and will probably never improve.  To engineer a good system you need to have a constructive and positive way to deal with mistakes that occur in code, architecture and process. Discordance on the team causes mistakes to be viewed as validation of an opposing viewpoint.  It’s an extremely counterproductive and demoralizing environment.  It leads to less communication as many people will avoid the conflict, and in one case I felt that I had achieved a level of fatigue and I just stopped caring, I bailed shortly after.

The LCD team illustrates why so many software projects have problems, in the above case the project failed after I left, in part due to the dysfunctional nature of the team.  My goal here is not harp on the negative but to use this as negative space for what you really want.  The opposite of this is a team that aspires to be great and to be more than the sum of its parts. I know it sounds like a cliché but I really believe a good team is one were the stronger developers help the weaker and less experienced developers become better because everyone wants to.  You want a team that can openly discuss and criticize aspects of the system and discover and fix mistakes early.  I think this can happen with a team of professionals who can put their ego aside to do good work and a strong leader who trusts their team and leads with fairness and wisdom and who is open to hearing input from the team but willing to make firm decisions.   Human nature in most cases probably precludes such a utopian software team, I think the goal here is to optimize and aspire to it.

No comments:

Post a Comment