Fungible, My Ass!

1 != 1 (that's "one does not equal one" for all you non-geeks) when you're talking about people. Sure, it holds true for bits of data, produce, and gold. People are different.

Martin Heller agreed with Richard Rabins when he said "Software developers are not fungible commodities to be bought and sold." That led to a post on Martin's InfoWorld blog, Strategic Developer, a couple of weeks ago. At the time, I was pleased to see Alpha Software mentioned on the InfoWorld site, but I was also a bit surprised by the content of Martin's mention. Doesn't everyone already know developers are not a commodity, let alone a fungible one?

Apparently not! After two weeks, Martin got such varied responses to his agreement with Richard's assertion that he's made a second post just to summarize the discussion.

I have to admit that I am not overly surprised by the disagreement and wide range of opinions even though I think it is pretty much common sense that while you can substitute one bushel of corn for another, you cannot substitute one worker for another. And notice I said "worker", not developer. Sure, I work in technology and the developer is more directly visible to my colleagues, peers, and me, but it is just as true when applied to ditch diggers.

The counter argument that tries to say workers are fungible usually goes something like, "It's just a matter of training and education." You just can't teach certain things though - work ethic, aptitude, natural talent, etc.

Next time you drive by a road crew "working", notice the 1 or 2 people doing the actual work while many more look on. Sure, I'm stereotyping here, but stereotypes come from reality. Chances are that those 1 or 2 doing the work have a better work ethic than the others. Yeah, they could just be the new guys that get dumped on, I'm sure that happens too. But I personally know several people that work in similar environments yet consistently work reliably while others look on or otherwise waste time - not because someone is cracking a whip or hazing them, but because they feel that it is their duty to do so. You just can't teach that.

Now go to your local auto mechanic, car dealership or oil change chain and walk into the repair bay, or peer in closely while standing next to the ominous "insurance regulations do not permit..." sign. If there is more than one mechanic working, I bet you'll see some differences in the way they get work done. Sometimes it's just a matter of work ethic, but I know even from my very early work experience that it is often something more. My father owns a gas station and auto repair shop (with a woefully out of date web site) and I worked there through junior high and high school. While there, I observed my brothers as well as other employees and how they worked. Even within my own family that shared a similar work ethic, there were distinct differences. One of my brothers just was not as good despite his best efforts. He wasn't doing anything wrong, he wasn't lazy, and he wasn't stupid. But his hands just didn't hold the tools as comfortably and his mind didn't visualize the problem as well. We all got the same "training" growing up working on cars, but you just can't learn what he didn't have.

In some cases, persistence can make up for skill and vice versa. The ditch digger that holds his shovel awkwardly can work faster in an attempt to move as much dirt as someone else, while the lazy digger that has outstanding technique can still move plenty of dirt too. Yet neither of these folks will accomplish as much as a skilled, motivated and natural person. And let's not forget that the awkward person is going to tire and slow down or even burn out completely and the lazy person is going to impact everyone else's morale.

In the world of programming, these differences often have more insidious effects. If your work crew has a lousy ditch digger, you'll probably know it at the end of the day when you see his work compared to the rest. But a programmer that's not up to snuff may very well write some code that appears to function well and do it in a timely manner. For now...

Let me make it clear that I'm not talking about just a bug here. We've all mistyped something, worked a bit too late in an effort to get just a little more done for the day, created a routine that was off by 1, or generally made some other kind of "silly" mistake. These "simple" bugs can be dangerous too, but they will not run rampant and consume your code like that guy that you hired just because he seemed like he'd work for a bit less than the other candidates.

Does he stink at building algorithms because his mind simply doesn't work that way so he ends up introducing what functionally amounts to a back door with the potential for a massive Hanaford-scale data breach? Or maybe his weakness is in conceptualizing threading and now your application is full of race conditions. Perhaps his specialty is uninitialized variables that lead to unpredictable behavior even though he's been taught repeatedly to always initialize them, but he just doesn't see the need to do so.

There's an easy solution here though. Find, hire and retain the best people that you can. And when the occasional lousy one slips through the cracks and gets a job working for you, don't hesitate to get rid of him.