Resume Driven Development

Before you ask HR to find a developer skilled in a particular tool or language, think about who you really want in that seat.


I had a conversation recently with Martin Thompson (@mjpt777), a London-based developer who specializes in performance and low-latency systems. I learned about Martin through Kevlin Henney’s Tweets about his recent talk at Goto Aarhus.

We talked about a disturbing trend in software development: Resume Driven Development, or RDD. Resume Driven Development happens when your group needs to hire a developer. It’s very hard to tell a non-technical HR person that you need someone who can make good decisions about software architecture, someone who knows the difference between clean code and messy code, and someone who’s able to look at a code base and see what’s unnecessary and what can be simplified. We frequently can’t do that ourselves. So management says, “oh, we just added Redis to the application, so we’ll need a Redis developer.” That’s great — it’s easy to throw out resumes that don’t say Redis; it’s easy to look for certifications; and sooner or later, you have a Redis developer at a desk. Maybe even a good one.

And what does your Redis developer do? He does Redis, of course. So, you’re bound to have an application with a lot of Redis in it. Whenever he sees a problem that can be solved with Redis, that’s what he’ll do. It’s what you hired him for. You’re happy; he’s happy. Except your application is now being optimized to fit the resumes of the people you hired, not the requirements of your users.

I have nothing against Redis. Substitute any other great tool (Node, Django, jQuery, AngularJS — the list is very long) in any tier of the application, and you’ll end up with the same story. If this scenario bears any resemblance to the truth (and it certainly does), you probably will rinse, substitute some other tool, and repeat. Now you have a developer whose job is to make sure there’s a lot of Angular in the system. Sooner or later, you have a nice “full stack” that’s using just about everything in the modern bestiary of programming languages and frameworks.

This isn’t a good situation. The problem isn’t the tools, each of which serves a need and is good at doing what it does. The problem isn’t the developers; you hired good Redis, Angular, and Node developers, and they’re all doing what they were hired to do. The problem is that your team is optimized around the inability to communicate at a critical stage: the inability of a technical team to specify what they really want (a developer with good programming taste and instincts), and instead hiring someone who has a particular skill or credential. Martin and I suspect that Resume Driven Development is quite pervasive: an overly complex application stack that’s defined by the people you hired, and by the current toys that the “cool kids” on the programming block get to play with, not by the requirements of the application.

If it all works, what’s the problem? Well, the problem is that it probably doesn’t work. Martin has gotten latencies from tens of seconds down to sub-second levels just by stripping layers out of the stack. The resulting code is simpler, easier to work with, and much more productive: customers buy stuff; customers actually explore the site and shop because they’re no longer frustrated while waiting around for their request to percolate through an overly complex site.

This isn’t an easy problem to solve. The complete system (software, engineers, HR staff) tends to optimize around the wrong problem: simplifying the process of evaluating candidates by listing a set of skills. In the process, it pessimizes what should be most important: the ability to serve customers effectively. The result is a large, complex technology stack, a Yak with a lot of multi-colored hair to shave, that’s defined by the institutional setting, not the job’s real technical requirements.

How do we fix this? It’s easy to say “hire good people”; but hiring good people is hard. When you’re looking for good programming instincts and a solid understanding of the fundamentals, certifications don’t help; degrees don’t help. But certainly understanding the problem, understanding why your “full stack” has grown so full, is a start. And before you ask HR to find a developer who is familiar with AcuteJS and Lymph, think about who you really want in that seat.

Cropped image on article and category pages by Howard Lake on Flickr, used under a Creative Commons license.

tags: , ,

Get the O’Reilly Programming Newsletter

Weekly insight from industry insiders. Plus exclusive content and offers.

  • Dan S

    True, but also true of management consultants and many other specialists

  • Though perhaps a bit risky, I think it makes sense to hire people that don’t have experience with the technology you intend on using. This forces the person into a new situation, forces them to think about what is happening, and pushes them into trying new tools. Many new hires may simply fail at this task, but at least you find out quickly that you don’t have the right person.

  • Ivo

    Developers are not resources, but humans, therefore HR should not hire them. Instead, existing developers must do that. HR might help here with technicalities of the hiring process, but evaluation of the next potential candidate should be done by the team itself! It works good, I have experienced that myself.

  • This got me thinking — my comments are here: “Problems With Résumé Driven Hiring” .

  • AndyX

    There is a much worse systemic problem that has been going on for a much longer time: RDD (from the other side).

    I’ve been in software for 40+ years. In the “early days”, there were fewer languages and platforms, so the focus was on problem solving, optimization, and the cost of maintenance.
    Fast forward say 25 or 30 years. The platforms have expanded exponentially, as have the languages, methodologies and design. I cannot begin to tell you the number of times I’ve been in meetings, formal and otherwise, in which developers were driven by which language or package would look good on their resume, and that that was the decision criteria.
    There were (and are) many reasons for this behavior. Over the last 10 years with the emphasis on Java, Web programming, Dev Ops, etc., most corporations no longer even know what is in their development stack — regardless the corporation’s formal position.

    The behavior is understandable if one comprehends the pressure to know (or know of) practically every current major language, package, and technology trend that comes along — and they are coming quickly. When you add the pressures generated by Agile development, unrealistically hyped development cycles, constantly changing tool sets, and employment uncertainty, developers are forced into being defensive: They must have a grasp on the latest industry trends. Therefore, the technology they choose is the one that will allow delivery in the compressed time cycles (after a quick trip to the internet), not necessarily the one best suited to the task. This may well lead to severe instability of the corporate stack due to the competing forces that shape human behavior. Consider that many of the COBOL programs written in the 70’s and 80’s are still running, ask yourselves how many of the client-server programs we write today will last that long. We may well reach a point where there is no available talent that understands what we have, why it is there, and how to move forward to the “next big thing”.