We’re not “resources”

The main thrust of the argument is that "resources" implies some kind of average, that developers are interchangeable cogs in the wheel. But Peopleware taught us that there can be an order of magnitude difference between the best and average developers, so your scheduling and estimates are based not on some abstract "resource" but on the talent of the person involved. Talent matters. You have to build a winning team with talent, not by scheduling "resources" who you think are interchangeable. Those people are inherently NOT interchangeable due to varying levels of talent.

Who wants to be thought of out of context? I want airlines to think of me as a passenger, and doctors to think of me as a patient -- I don't think I'll get better results if they think of me as a unique and special human being.<p>Why add mental overhead?

My first degree is actually in Mech Eng, not CS. To us, a "resource" is something you use up and then discard. Coincidentally, that's also the HR definition.

But we are resourceful. Sometimes at justifying our own special, unique, boneheaded worldview.<p>Don't send a Stallman to do a Kay's work (or vice-versa).

Here is an easy workaround to the "programmer = resource" question. If I make 50/hr as a programmer than the cost per day of me as a programming resource is 50<i>8 = 400. Now we can add an "Efficiency coefficient" to account for how skilled I am. So, the default cost for our programming "resource" per day is:<p>ResourceCostPerDay = HourlyRate</i>8<i>EfficiencyCoefficient<p>If this coeff. defaults to 1 then in my example:<p>ResourceCostPerDay = 50</i>8<i>1 = 400<p>If I am really super good we can change this to have a coeff. of 1.5 so<p>ResourceCostPerDay = 50</i>8<i>1.5 = 600<p>If I totally suck we can change the coeff. to 0.5 so<p>ResourceCostPerDay = 50</i>8*0.5 = 200<p>So by having a simple "efficiency coefficient" the resource cost for a programmer can indeed be modeled fine, so with due respect to the person who posted this article, he is mistaken: a programmer or engineer (speaking as a test automation engineer myself) can indeed by quantified quite well as a "resource" like any other "resource" such as the number of application servers a company has. Reductionist? Yes. But this is a reductionist universe. Deal with it. :-)