Imagine a simple (and somewhat boring) card game. In each round, all
players are dealt one card each. Each player may hold at most three cards
(so after the third round they must start discarding). After an arbitrary
number of rounds, the player with the highest card total wins.
The strategy is pretty simple: when forced to discard, always discard your
lowest card. No rocket science here: when you can’t control the cards
you’re dealt, you win by eliminating the weakest of your holdings.
This seems to be a reasonable strategy in any situation where you need to
optimize some collection of "things," but where the resources you
receive have unknown characteristics.
Our industry is suffering from an embarrassment of bad programmers. Much of
the blame can be leveled at the hiring frenzy that occurred during the dot
com boom, where anyone who could play Quake (or who had once watched
someone play Quake) could get a job coding (and playing foosball at work).
Many of these people are still in the industry.
So now we have a problem. Interviewing and recruiting good people is very
difficult; For most organizations we’ve seen it’s a hit or miss
affair. This means that the bad get let in along with the good (just like
being dealt random cards). However, once the bad folks have been hired, it
turns out to be hard to fire them. Unlike the card game, they stay in your
hand, dragging down your overall score.
There are three things to be done here. First, companies could get better
at recruiting. Unfortunately, one of the best indicators available to
recruitors, past performance, is hard to come by. In the US at least,
employers now tend to give anodyne references to ex-employees rather than
tell the truth and risk being sued.
Second, we could find a way to fire the ineffective developers. If that
happened enough times to an individual, they might get the hint and leave
the industry (which would be good for all of us). Unfortunately,
that’s also unlikely to happen. Even though most developers in the US
are employees at-will (meaning they are in theory employed at the whim of
their employer), in reality the various anti-discrimination laws make
firing a risky business for most companies.
Our third strategy isn’t available to the card players: we can
improve the individual cards in our hand. This means working hard to train
and retrain folks, not just in the specifics of technologies and languages,
but also in the soft disciplines: communications, business practices, and
so on. Some developers aren’t trainable, but I’m thinking that
the vast majority will benefit.
Interestingly, there are companies who recognize the value of attrition.
GE, for example, has every level of manager rank their employees. After
justifying these ranks to the manager’s manager, the company then
puts in place an action plan for the bottom 10% (a plan which can include
termination, a performance improvement plan with a time limit, or a move to
a more suitable position). I don’t think I like the rigidity of GEs
policy (at least as externally stated), but I think the intention is good.
Over the next few years, we all have to do something to improve the quality
of the work delivered by our industry. If we don’t,
we’ll find legislators doing it for us (possibly with professional
licensing schemes and attempts to hold developers liable for faults in
software). And improving the quality of work means improving the quality of
the development community. Maybe it would be in our long-term interests to
find ways to make recruiting more reliable (perhaps by setting up a way for
employers to comment truthfully on a developer’s past performance).
We need to make it easier to fire the truly bad developers (contract to
hire and probationary periods are a good interim measure). And we need to
find ways to promote on-going professional training. If we don’t help
ourselves, someone in government will do it to us.