Punishment driven development

I'm a big fan of agile development. One of the key concepts that I like the most is story point estimation. The best suggestion I ever heard was to estimate the size of your stories in terms of gummy bears (at which point you can come up with possibly one of the best units of progress measurement, gummy bears / iteration), thereby making sure that nobody gets the impression that you're actually quoting any sort of real unit of time.

The exact opposite of this is trying to estimate stories in an agile project in terms of hours. All too often, even though these realistically are no more than "ideal hours", they are taken literally by everybody and if a developer doesn't manage to "burn down" 80 hours of development per week, they risk being told to either work harder or estimate better (it's often left ambiguous which solution is preferable), leading to what can possibly best be described as punishment driven development.

The unfortunate fact is, there is a certain inherent complexity to software development that's very difficult to account for accurately, so the best way of going about things seems to adopt an approach that assumes that people will at least estimate wrongly consistently (and use that consistency to come up with increasingly accurate velocity forecasts).

CVs, resumes and outright fiction

If there's one thing that I've learnt the hard way from interviewing software developers, it's the ability for a resume to tell you so much more than the person writing it ever could about themselves, mostly because quite often a lot of the competence these documents convey seem to be finely crafted works of fiction.

Warning signs that the person that you're about to consider entrusting lots of responsibility to might not be the best candidate you could hope for, seem to be 4 words: "I was involved in...". This fantastic phrase could actually mean anything from "I single-handedly wrote every last line of code " to "I occasionally made the guy doing the work a cup of tea", but I'm coming to the conclusion that more often than not, the facts are more likely to involve boiling water and milk than saving the day against all odds.

Other things that I've learnt to raise an eyebrow at, include listing internal awards handed out by an organisation that have no meaning outside of the internal company politics ("Won best documentation award" being one of my favourites) and writing more about what a company does for a living than what a person actually did during their time there.