Why don’t developers want the latest toys?

on May 25, 10 • by Gwyn Fisher • with 2 Comments

There’s a tradition in R&D management that goes something like this: “give them toys and they’ll be happy.” Typically this has meant the biggest monitors, or the fastest CPUs, or an egregiously unnecessary SLI GPU configuration (for, ahem, high capacity computation tasks, right…), or whatever the latest...

Home » General Coding » Why don’t developers want the latest toys?

There’s a tradition in R&D management that goes something like this: “give them toys and they’ll be happy.” Typically this has meant the biggest monitors, or the fastest CPUs, or an egregiously unnecessary SLI GPU configuration (for, ahem, high capacity computation tasks, right…), or whatever the latest piece of hardware might be that catches the purchasing manager’s eye.

But what about the software on that hardware? Sure, we equip people with an IDE (if they’ll use it, or whatever text editor they demand if they won’t) and whatever other tools are mandated as part of their development lifecycle. In fact, typical managers would dearly love to be able to mandate more tools for their developers. It’s easy, after all, for a manager to make the correlation that more toys = happy developer = more productivity = more code = bigger bonus = happy manager.

So why do so many developers, particularly in the embedded space, use outdated software tools? What’s the excuse, after all, for vi or some close derivative being a dominant code editor?

Inverse snobbery has been a popular theme in the privileged parts of the world for much of the last thirty years. “Yes, we drive a Lada because we just don’t believe that a BMW is necessary.” Really? Does anybody actually believe that tripe? I mean, I can well believe “I use vi because I have to; it’s the only editor that works on this cruddy piece of hardware.” But forgive me if I have a hard time with “I use vi because I like it better than anything else.” We all get used to stuff that makes no real sense, but surely there’s a point where even the most inverted technical snob has to look themselves in the mirror and know, deep in their darkest most hidden-away recesses of existential reality, that they’re just full of it.

Intransigence. Inertia. Feet dug in harder than you could possibly shift in a lifetime. Call it what you will, but unless something life-changing, like a project in a new language happens, many developers have a nasty habit of sticking with what they know. “What we do is hard enough,” goes the meme, “we don’t need to make it any worse.”

So how are those same developers coping with the demands of the ever-increasing footprint that is professional development? After all, it’s not enough anymore to simply bang out some code and check it in, moving on to the next assignment and hoping nobody notices. Now the professional developer is tasked with unit testing, performance testing, static analysis, memory profiling, code review, refactoring for maintenance, architectural cohesion, you name it. The list only ever gets longer as we move the goal posts for QA closer and closer to the consumer, requiring the developer to pick up the slack in the interim.

How does that footprint get coverage? There are still the same number of hours in the day, and the required amount of code generated by each developer hasn’t markedly decreased over the last 10 years. So what gives? One thing’s for sure… vi hasn’t made developer productivity much better than when it was first written at Berkley all those years ago (with all due deference to the strides made by vim/gvim in recent years).

I’m going to examine several different communities in upcoming posts and look at the approach they take to solving this problem, covering a range of backgrounds and roles from embedded driver writers to creators of modern web applications. In the meantime, have a look inside yourself and, if you pass muster as some analog of the crusty vi user I paint above, ask yourself why, and what might make you change. Recent history abounds with case studies, some of which I’ll reference, but at the end of the day it’s all about you and your personal work practice.

Related Posts

2 Responses to Why don’t developers want the latest toys?

  1. Gwyn says:

    Hi Walt! Ah, the editor wars… good times! Not going to (can’t, certainly) argue with the muscle memory notion — heck, I still use vim on occasion (and yes, I got in hot water with some of my own developers for this particular post ;p). But the point is, as you say yourself, if the tool exists, use it. You may reach for an older, more familiar tool on occasion, you may still find corner cases (or muscle memory) that help you get significant value from it. But contrast that with the design tools, the equivalents of IntelliSense, or refactoring, or profiling, or integrated debugging (don’t, just don’t, tell me gdb is all that and a bag of chips!), and from a productivity perspective (I’m a pointy-haired manager, remember) there’s really no contest. Certainly there are good reasons to use old tools (hardware limitations, cross-O/S usage, whatever), but the heads-down “it’s good enough for me” Luddite attitude shown by some (certainly not all, and not in any way wanting to bucket you with them) is remarkable for an industry known for constant innovation.

  2. Walt says:

    Afraid I have a problem with you having a problem with someone using a tool because they “like it ” better than anything else. Specifically VI.

    I use IDEs if they exist for the tool I’m using. But If I have to crank out a volumne of code, I fire up gvim. Why? Not because it’s necessarily the best editor around (I don’t want to start that war) but becasue I have 25 years of muscle memory using it.

    I don’t think the key strokes; I think “move that over” “copy that down” “substitute globally” and some lower part of my brain knows what to do.

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Scroll to top