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.
No comments:
Post a Comment