Friday, November 7, 2008

Programming to the lowest common denominator

I regularly observe programming to the lowest common denominator in software development teams. It is especially prevalent in teams associated with large organisations.

What do I mean by programming to the lowest common denominator?

Taking a hit for the team

There is currently great emphasis on team members being able to easily understand each other's code. I am not going to comment on that idea itself, just a possible consequence of it:

I don't know where you work, but on our team of 15 or so developers there's no room for a person who writes code the others can't read. Some of us are smart enough to do so, but all of us are smart enough to know that we shouldn't.
From a thread on a local user group.

So here we have a case where if you could write some code that is "better", but is not "readable" by other team members, then you can't write it. What happens if there is a significant difference between the least and most competent programmers on the team (and I observe that there often is)?

Business continuity

Another pervasive force is from management. Business is generally concerned with the risk that the original developer(s) of a particular software application won't be available one day and so they wish to be able to find others who can take over in a timely and cost-effective manner. So business standardises on what they perceive as common skills, tools and languages, which by definition of being common enough is a low standard.

If the previous two points hold, then we now have a situation where business chooses a low standard and and then team members are expected to to work in a low subset of the low standard. Sounds like fun!

I am going to assume that some of the members of these teams are highly intelligent and care a great deal about well they do their work. Now they know, at least subconsciously, that they have to work within these constraints otherwise they won't have that job. I observe that some of them deal with that situation by focusing their attention on just the possibilities that are actually open to them (and perhaps just a little beyond the boundaries). This is actually a very small world, compared to all the possible programming skills, languages, tools, etc.

The sad part though, is when people have internalised that (relatively) little world and they start to emotionally/irrationally defend it and even evangalise it (like in the post above). I admit to being in this situation in the past - you can debate the intelligent part. :-)

No comments: