[GTALUG] Resume Driven Development

David Collier-Brown davec-b at rogers.com
Mon Oct 13 16:40:39 UTC 2014


This is an interesting side discussion to the problem of HR departments 
filtering out the good people and passing on people with the highest 
number of keyword matches to the hiring managers.

[This one keeps coming up in both GTALUG and UU discussions: crossposted.]

--dave
-------- Original Message --------
Subject: 	Resume Driven Development
Date: 	Sat, 11 Oct 2014 13:38:37 GMT
From: 	<Mike Loukides>


http://feedproxy.google.com/~r/oreilly/radar/atom/~3/vgBYi2NC_FY/resume-driven-development.html

Resume Driven Development

Crossed_Wires_Howard_Lake_Flickr 
<https://www.flickr.com/photos/howardlake/4834299551>

I had a conversation recently with Martin Thompson 
<http://mechanical-sympathy.blogspot.com/> (@mjpt777 
<https://twitter.com/mjpt777>), a London-based developer who specializes 
in performance and low-latency systems. I learned about Martin through 
Kevlin Henney’s Tweets <https://twitter.com/KevlinHenney> about his 
recent talk at Goto Aarhus 
<http://gotocon.com/aarhus-2014/speaker/Martin+Thompson>.

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 guys, 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 
<https://www.flickr.com/photos/howardlake/4834299551>, used under a 
Creative Commons license <https://creativecommons.org/licenses/by-sa/2.0/>./

<http://feeds.feedburner.com/%7Eff/oreilly/radar/atom?a=vgBYi2NC_FY:8OLvyutoYS8:V_sGLiPBpWU> 
<http://feeds.feedburner.com/%7Eff/oreilly/radar/atom?a=vgBYi2NC_FY:8OLvyutoYS8:yIl2AUoC8zA> 
<http://feeds.feedburner.com/%7Eff/oreilly/radar/atom?a=vgBYi2NC_FY:8OLvyutoYS8:JEwB19i1-c4> 
<http://feeds.feedburner.com/%7Eff/oreilly/radar/atom?a=vgBYi2NC_FY:8OLvyutoYS8:7Q72WNTAKBA> 
<http://feeds.feedburner.com/%7Eff/oreilly/radar/atom?a=vgBYi2NC_FY:8OLvyutoYS8:qj6IDK7rITs> 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gtalug.org/pipermail/talk/attachments/20141013/100f40f7/attachment.html>


More information about the talk mailing list