Why software developers can be like bad TSA agents (and how we try to avoid it).
This weekend, my family and I flew from Missouri to Delaware to visit my brother who’s in the air force. We nearly missed our flight in St Louis because of a very dedicated TSA agent who spent 15 minutes investigating a small jar of baby food in our diaper bag.
He was concerned because the ingredients list included fruit juice from concentrate. You see, that’s a liquid, and it’s liquid we’re really concerned about. If the ingredients list only had solids, there wouldn’t be a problem. I was floored. This man never questioned what was actually inside the opaque container. He trusted fully that whatever was in there was as specified on the ingredients list. When he read “grape juice,” he knew that was a liquid, and that they were supposed to screen liquids. He radioed for backup from other TSA agents (no joke) and after a lengthy discussion, decided to run it through the x-ray machine again, just in case.
What made this guy so rigid in his thinking that he aggressively screened a substance that he was 100% convinced was grape juice? I’ll tell you my opinion.
He was taught a skill and how to apply that skill algorithmically, as a systematic way of accomplishing a goal. The skill is baggage screening; the goal is to prevent dangerous substances from be taken onto an airplane (a worthy motive). He’s given guidelines like “here’s how you screen a liquid to make sure it isn’t some sort of explosive” and then told to apply it to any liquid he runs into. It doesn’t matter whether it makes sense, he just has to do things the way he’s been told to do them, replacing what should be done with what he knows how to do and hoping that will be good enough.
Welcome to software development.
As frustrated as I was with that guy, many of us in the software field are no better. We become “Rails programmers” or “Java gurus” or “.Net Masters,” and no matter what problem we’re confronted with, we’re PRETTY SURE we can solve it with the set of tools we’re already very experienced with. My goal is to produce an efficient and functional product, my skill is writing rails applications, and I’ve been guilty of conflating the two and presumptuously deciding that my actual goal is to produce a rails app that does what this client wants because, hey, that’s what I’m good at!
Here at 12 Spokes, we recognize how easy it’d be to get stuck in a TSA rut because the tools we use will eventually fall by the wayside (are there even any COBOL shops left?). We want to avoid that rut. We want to spread out across the technological landscape and have enough knowledge to determine the right tool for the right job.
That’s why every developer here has the authority to spend a little time every week playing with a new tool or reading about a new language. I have spent time with Titanium for mobile apps, advanced coffeescript, node.js, and backbone, and I’ve got plans for dives into many other technologies in the future. I love that fact, and I think it makes me a more well rounded asset than the one-track-code-machine I would be otherwise.
If you’re interested in moving your team away from specific skills and toward the goal of producing the right solution for your clients, check out the “Thoughtworks Technology Radar.” It’s a good (and opinionated) starting point for picking up the pulse of current developments in the software ecosystem.