Factory workers on a production line

We are People not Resources; The poisonous ‘R’ word

Factory workers on a production line

Disclaimer: The slightly vitriolic parts of this post are not aimed at anyone in particular! 🙂

What is a ‘resource’

Where I work many of the staff have a habit of referring to people who ‘do’ stuff (like software developers, testers, web designers etc) as ‘resources’. They don’t use it as some benign collective noun, it is used to refer to individual people explicitly! Here are some examples of usage that I hear daily:

  • How many resources are working on that?
  • We need some more design resource for that project.
  • I have a spare resource this week, what should he work on?
  • Which resource is picking up this bug?
  • I need to refer to my resource plan

These sorts of phrases are uttered by people as though it were perfectly normal. The terminology is so conventional they might as well be asking what you had for breakfast. As much as I would like to remain professional, my response to people who talk like this is F**K YOU! Quite frankly to refer to people who are educated, qualified, intelligent, experienced and passionate as ‘resources’ is incredibly offensive to say the least. This demeaning term implies that we are:

  • On a par with ‘materials’
  • As disposable as paper clips
  • All the same
  • Infinitely interchangeable and replaceable
  • Little more than numbers on a balance sheet

Clearly this is not the case.

There is much literature written about the sociological aspects of software development teams which is beyond the scope of this post but it is immediately apparent to anyone who has worked in a software development team that none of the above statements are true. So why does this offensive practice continue?

My view is that the term is a symptom of a fundamentally broken but deep rooted approach to managing projects and people. The approach is an attempt to simplify software development and model it as though it were a factory production line. You’ve got your business analysts shoving requirements in at one end, the developers in the middle making the ‘goods’ which are then passed to the testers (or should I say test resources?) who allow a production quality product out the other end. Laughably my department was even once re-branded as a ‘Software Factory’. It’s enough to make you weep!

In this model the developers and testers are simply ‘resources’; generic units of man-power. The more you assign to a project, the faster the backlog of work is completed. With the factory model this is probably correct. If you have 5 people packing fudge and they can pack 500 boxes per hour between them, you would reasonably expect 10 fudge packers to be able to do 1000 boxes per hour. Same with software development right? We aren’t getting through the work quick enough, so let’s shove another 5 development resources on it, problem solved. Or not. In 1975 Fred Brooks published a book called “The Mythical Man Month” that discussed the fallacy inherent in this ideology, yet nearly 40 years later this is still going on and appears to be rife among companies that are household names.


The ‘R’ word is also poisonous because it seeks to widen the gap between the shop floor drones (i.e. the highly skilled software developers) and the ‘management’. Managers discuss what their resources are working on behind closed doors, shuffling people around on their ‘resource plans’ and hopelessly trying to make sense of the scheduling mess they have created with their flawed ideology. To me the usage of the word resource implies a certain ignorance of the fine art of scheduling software development projects.

At one point I got so sick of this that I launched a fight back against the ‘R’ word. I raised awareness of the word’s implicit evilness and explained that quite simply:

We are people not resources!

I put the word ‘resource’ on a par with the worst swear words and made people cough up a pound every time they uttered it. I’m not sure how much was collected in the end but it certainly got people thinking and the team had a nice bit of cash to spend at the Xmas party!

So please join me in the fight against this most disgusting of terms and tell your management that you’re a person not a resource! Correct them when they use the term in your presence. Tell them that Dilbert is satire, not an instruction manual. Ask them to read Brooks’ book and step out of the 1970s.

Github Logo - Octocat

Git for ugly and stupid people; a git tutorial for subversion users

Github Logo - Octocat

Why Git for Ugly and Stupid people then? What’s this got to do with Subversion?

According to Linus Torvalds (author of git and some OS called ‘Linux’ or something) you are ugly and stupid if you don’t use git. Really, he said that!

OK so I’m ugly and stupid, now what?

Where I work we are doing what many software teams are doing and slowly making the transition from subversion to git. The switch is motivated by the desire to move to an SCM that is distributed, powerful and has a good SaaS provider we can utilise (GitHub in our case). Git was the obvious choice and we started trialling it just over a year ago. Since then we’ve forced all developers working on ‘new’ stuff to use GitHub instead of our co-located subversion servers.

The initial switch was far from smooth and to be honest none of use really knew what we were doing! After a bit of trial and error we eventually learnt enough to be able to cobble together a decent workflow that we’ve been evolving ever since. We’re now getting to the sort of critical mass of developers using git that it is no longer practical to mentor everybody to get them up to speed myself. So I took the plunge and started writing some docs to go in our new starter guide that explains what the hell git it, how it works and specifically how we use it day to day to get stuff done. Because the guide is aimed at developers moving from subversion it uses subversion as a reference point and tries to illustrate how git differs.

I’ll be honest, the guide is quite long but it very much demonstrates the key ‘eureka’ moments that I had while learning git. Those times where something suddenly clicks in your head and whole swathes of head scratching moments are suddenly swept aside in a wave of clarity! The guide is basically what I would have wanted to read in order to understand what I was actually doing when I was fiddling around with git commands a year ago.

Because it is so long I’ve split it into smaller, more digestible parts and I’m putting it up here for the wider world to see. Yes, I know, there are hundreds of git guides out there but one more can’t hurt surely! 😉 Here goes…

Next section – Distribution and Commits