On Grails and Groovy

One of the things I've been getting more and more into during the last year or so is the Groovy language and the Grails framework.

Leaving aside for a second performance concerns with Groovy (most of which aren't going to make a big difference to typical web apps), the Grails framework is amazing in terms of the sheer productivity gain you get compared to typical enterprise Java development.

The Groovy language in and of itself is a certainly a breath of fresh air compared to good old Java, but being basically a "By Convention" layer on top of spring and hibernate, Grails is the real killer here. It simply lets you spend most of your time focusing on what actually matters, namely the business logic. Now the more used I'm getting to being able to leave (most) configuration details to the underlying framework, the more arcane it seems to have to touch something as unproductive as an XML bean definition file, a hibernate mapping or even fancy spring and JPA annotations.

Maybe I'm getting lazy, but sometimes having things just work out of the box is downright nice.

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.