I’ve spent the last 18 years as a professional software developer. I’ve had loads of jobs, both as a ‘permie’ and as a freelancer/contractor. I reckon I must have read over a thousand job ads which I’ve looked into, that is I’d had more information about the job from sources other than the advert or the agency that published it.  I’ve learned one thing: to read between the lines.  IT recruiters speak a different language to us,  a language rich with subtlety and innuendo, a language which might seem simple at first but hides deeper meaning. As a service to the community I now present a handy translator from IT-recruiter-ish to common English. Make sure you look it up next time you see the job-advert of your dreams. 

PS: this is work in progress. If there’s something I missed feel free to comment here and I’ll add it to the list.

A luxury beach house or a hut? Depends on who's looking at it.

I got inspired to write this after reading one of Mike Cohn’s recent blog posts. Now, before I begin, let’s get one thing straight: I agree with probably everything Mike has ever written about Scrum and Agile and I’ve learned a lot from his book ‘Succeeding with Agile’, which is essential reading for anyone practising Scrum. Did I say I agree with everything? I meant nearly everything ;).  Story-point estimation is the point on which I beg to differ. It’s my major bug-bear with Scrum, the one thing that I find ‘not fit for purpose’, broken, not working, kaput.

Mike, in his post, likens the definition of a story-point to the definition of a “yard”, i.e. a standard unit of measurement that can be agreed upon by everyone. The reasoning goes that, if everyone can agree on how long a yard is, then everyone can agree on how long a mile or an inch is and therefore have a standard frame of reference for future estimations. That would be fine and dandy if we had a real chunk of code which represented the true length of King Henry’s arm (say, for instance, Matz’s MRI code(1) ). The thing is, there’s no such thing as a ‘yard’ in software development. There’s no universal measure of how complex or long or time-consuming something is. Take what’s probably the simplest unit of measurement in the coding world: the ‘hello world!’ app. In something like Ruby, Perl, or even JavaScript(2) it’s one simple line of code. In Java it’s three or four and brings into play importing libraries, object-orientation, the main function, even the file system itself. So to a Java developer a ‘yard’ will always be much longer(3) and more complex than to a Ruby/Perl developer.

Moreover, a yard remains ever unchanging and unchangeable, unaffected by the whims of man or nature. Whether you’re tired or beaming with energy, in a good mood or in a bad mood, full of cynical experience or optimistically naive, a yard is a yard is a yard is a yard.  The same cannot be said about good ol’ story-points. Something that appears very complex or time-consuming today may well appear simple and quickly-solvable tomorrow. Knowledge is power and if I had a penny for every time I came back a week later and re-adjusted my estimate downwards for a previous story after learning a bit more about the relevant domain, well….I’d probably have enough money to buy myself a pizza. Not just any pizza, I’m talking 16 inch, thick-pan, filled crust here, the works. That’s a lot of pennies right there!

Not only that, but the way we define a ‘yard’ in software changes dependent on the observer’s technical perspective and even psychological or emotional state. Factors like personal and team morale, inter-personal relationships, outside influences, e.t.c. they all affect our ability to tell how time-consuming or complex a story is. On a ‘good’(4) day I feel there’s nothing I can’t achieve and my estimates tend to be overly optimistic, reflecting my psyche.  Conversely, when things are gloomy so are my estimates - everything seems like a huge chore to me. My definition of a ‘yard’ keeps changing, victim to a dozen or more fluctuating factors, none of which are taken into account when we come to ‘agree’ on an estimate during our planning poker. In every single planning meeting I’ve attended, ‘consensus’ is always closer to the estimate of the most senior/influential/charismatic person in the room. Trying to give objective estimates during planning poker is a bit like trying to avoid taking drugs at a Grateful Dead gig: peer pressure will prevail in the end. Still, I can envisage an environment where planning poker works fine. The trouble is, that environment consists of closely-knit team-members of similar experience, skill, background and ‘status’(5). Last time I checked there weren’t many dev teams like that!So what are we to do? Well, we can always fall back on Joel’s evidence-based scheduling approach. Or we can get Story-point estimation working right, using more objective measurements and accounting for a number of technical and environmental factors. I have some thoughts on this but they’ll have to come out at a later post as this one’s already getting too long.

Footnotes:
(1) feel free to replace with your chosen bit of legendary coding.
(2) not accounting for the surrounding HTML
(3) I’m not having a go at Java (this time), just making a point about complexity and size.
(4) I don’t have many of these, to be honest.
(5) For want of a better word.

Here’s a scene: you’re in the interview room at a really exciting company, being interviewed for your dream job.  You’ve already aced the technical interview and really hit it off with the team leader and the other team members. You can already imagine yourself happily working there. But just before you start visualising your first ‘employee of the year’ award, another person walks in the room. They introduce theirselves as the HR manager and ask if you mind being asked some more questions. ‘So, Fred’, goes the first one ‘what is your biggest weakness?’ ‘Ermm..’ you fumble, ‘..Ben & Jerry’s, I suppose’.  ‘No’, the HR person goes, ‘I meant as a professional developer’. ‘Why didn’t you say so’, says you, ‘in that case it has to be Herman Miller chairs. I’d sell my own grandmother for an Embody full mesh’.  ‘No, no, that’s not what I meant’ they say, ‘I meant a weakness in your abilities as a professional developer’. ‘Why would I tell you that’ you reply, ‘I’m trying to sell myself here, not bury myself’. At that point all the positive vibes you’ve built up have evaporated, your self-confidence is shaken and you’re beginning to wonder if this really is the right company for you. Yes, you’ve fallen victim to the….CURSE OF POINTLESS INTERVIEW QUESTIONS (ta-dah-dah).