Good news, there’s a new regular jazz venue in south London. I’ll be playing regularly with Brass Impact at Dulwich Hamlet football ground, with jazz every wednesday night. The full big band will be on once a fortnight with various small groups taking it in turns to fill the other weekly slot. Mark Nightingale, Pete King, Alan Barnes and Derek Nash have already been lined up to appear over the coming months so it’s looking very promising. Our first night is March 17th with the full band - do come along and help build a regular home for some of London’s finest musicians.

From the flyer:

JAZZ AT THE HAMLET - OPENING NIGHT WEDNESDAY 17th MARCH

Introducing the UK’s Best Jazz Talent each and every Wednesday night at Dulwich Hamlet Football Club. Opening Night 17th March with Brass Impact Big Band. 8.30 pm - 11.00 pm (Doors open 7.00 pm)

Entry £8.00 concessions £6.00

Dulwich Hamlet FC, Edgar Kail Way, East Dulwich SE22 8BD.

Fully licensed air conditioned lounge bar, serving wines, spirits, & real ales (comfortable seating & pleasant atmosphere) A rare treat not to be missed!

For more info: Tel 0207 274 8707

Forthcoming future artists include: Peter King Quartet with John Pierce, Andre Messeder & Bobby Worth, Sax Appeal with Derek Nash & his fantastic Band, The Dave O’Higgins Quartet.

Coming from a Java development background, I am used to intuitively knowing where to look for third-party libraries and tools to handle the heavy lifting for me. I have just started playing with a ruby on rails front end for a hobby project and am discovering it is so much harder to put together an application without this intuitive support.

For instance, I am building a web application to act as a client to a REST-based service that I am also writing. I have protected that REST service with HTTP digest authentication, and so need to provide my credentials from the rails client.

Rest Client is a very neat API for dealing with restful services, and I had it working a treat before I added authentication to my service. Like all of the other clients that I could find, basic authentication is supported fine but digest authentication is not. That even appears to be the case in ruby’s own Net::HTTP implementation.

As an aside, I started out with FeedTools before discovering that its atom support didn’t extend as far as handling item contents whose type was application/xml.

Ah, if there was only something like Apache’s HttpClient for Ruby…

I just had to comment on an interview with Linda Rensing about the similarities of gauging the effectiveness of agile with the placebo effect on InfoQ.

Unfortunately, I rather think that she misses the point. What’s brilliant about the medical community is that they have so much measurement in place that they are able to know how effective a specific treatment is in comparison to the placebo effect, and only those procedures that are proven to be better than placebo are kept. What’s missing from Linda’s interview is that software development doesn’t appear to be ready to apply the same level of measurement. So sure, talking about the process and spending a lot of energy introspecting on it should help. Making a change with the stated intent of it being for the better should help (there’s even the classic study with altering light levels in manufacturing that I can’t dig out a reference to at the moment). The crucial bit that’s missed here is how success is measured. If the only measure we have is by how well people think it’s going

The criteria by which we can say that agile has succeeded has to be whether it has outperformed the placebo effect. The problem is, you’ll need someone who is better at designing trials than me to work out how you do a double-blind test on the effectiveness of a process.

I’ve not worked for a company yet that didn’t have some form of annual employee appraisal process, usually undertaken by the line manager. These appraisals usually are a one-size-fits-all affair where a generic set of questions that may or may not be relevant to anyone in a programming department are paid lip service once, maybe twice, a year and then mostly forgotten about.

Now, wouldn’t a set of questions and metrics that were really relevant to your role actually perform a useful part of your professional development? If the appraisal process were to be transformed from an infrequent pain in the neck into a regular process of support and guidance, wouldn’t that be a wonderful thing that both appraiser and appraisee would look forward to?

So the first question is “why is the programming department so different to most other departments in a typical company?”. First, they’re always doing something that they’ve not done before. Sure, they’ve done other pieces of work like it before, but not like it enough to just be able to turn the handle and have another project clank off the end of the assembly line. Second, what they’re working on isn’t normally under their control. It’s pretty common to plan to be working on project X over the next couple of months, only for the priorities to shift and so you end up working on projects Y and Z instead. So, if you set delivering project X to be a target in someone’s appraisal (it certainly fits the usual S.M.A.R.T. criteria), it had better be with the understanding of all parties that there are likely to be countless circumstances under which that developer can have done a stellar job and still not have delivered that project.

Then we come to the really awkward question: “OK clever clogs, what should the appraisal process be?”. I suppose the cop out answer is that it’s down to you and whatever suits your organisation, but there really ought to be some part of it that is general enough to be useful to enough people. What’s more, I’m about to embark on this process with our own HR department so I’ll let you know how I get on and what we learn through the process. My plan at this initial stage is to think through and identify the core functions that each person in our team performs and to come up with something based around the Drefus model of skill acquisition to quantify how well they are performing that function. If nothing else, I do like the language involved by grading someone as being a novice through to an expert, rather than the dreaded 1-5 or below average through to excellent rankings I’ve seen in previous appraisal forms, it’s a lot less judgemental. At this stage, about the only criteria for success I have is whether appraisals become something to look forward to rather than a chore. The other benefits I’m hoping for, like better support for an individual’s professional development, are much harder to quantify and not something we are measuring with our current process.

I was struck, whilst reading Ben Goldacre’s excellent book, Bad Science, by the sheer volume of data surrounding medicine. Whether it’s disease rates in populations, probability of side effects per dosage, number of citizens with a particular condition, there is a huge volume of data to analyze and cross-reference.

The bit in particular that struck me is that these are very good datasets surrounding incredibly subjective measures; treatments, illnesses, symptoms and the like are all very woolly and open to wide interpretation, yet the medical community is still able to bring the full weight of statistics to bear (especially the bit about Cochrane meta-analysis of pre-existing studies that are able to spot statistically significant trends across studies that each of the individual studies were not able to do).

Software development doesn’t have anything like the same rigour and still completely relies upon subjective intuition applied to vanishingly small datasets (even huge multinational consultancies, working on hundreds of projects at any one time, are still working with a vanishingly small proportion of the total number of software projects).

I reckon there’s real scope for someone who really understands statistics to change the way we understand development techniques and methodologies. There isn’t even a recognised set of data that we should be collecting about software projects on which to found comparisons. Estimated time, actual effort, number of defects and cyclomatic complexity are all very good places to start, just off the top of my head, but I’m sure everyone will agree that much more measures will be necessary to build up a reasonable picture. Yes, there’s a growing number of people who think that agile development works and is more productive, produces code more quickly with less defects, delivers better business value and the like. I agree; from my wholly subjective perspective I think the projects that have been more agile have worked better, but my point here is that subjective opinion is not enough. Show me the numbers.

The downside is that I recognise I’m not even remotely qualified enough to perform this analysis myself. My understanding of statistics is rubbish. Does anyone know of suitable statistics resources?