I am Paul Wilson; Mere Complexities Limited, sells my consulting, coaching, and coding services. I am passionate about Agile, particularly Test Driven Development.
Crossing the chasm?
On yesterday's World at One (Tuesday 30 May 2006) Richard Bacon MP, member of the Public Accounts Committee was interviewed about the unfolding disaster that is "The National Programme for IT in the NHS":
"...there are shelf loads of advice saying when your doing a big project, do things bit by bit - incrementally. Go from the known to the unknown one step at a time. Don't try and do a big-bang."
"And its not like we haven't been here before: the Wessex Regional Health Authority disaster was such a big disaster because it was a big-bang scheme, dreamed up from the centre......"
Its great to see the message is finally trickling through.
There-Them-Then
During last week's course Joseph and Ben cunningly turned a disagreement on quality in software development into an exercise in conflict resolution.
I've later realised that we were all rehashing arguments we'd had with other people previously: one side was reliving previous fights against gold-plating and framework-building; the other against pressure to reduce estimates and cut-corners to meet unrealistic deadlines. There-Them-Then not Here-Us-Now.
Deep Dynamics of Agile Teams in Edinburgh
Last week was the Edinburgh Deep Dynamics of Agile Teams Course that I organised. It went very well, thanks for asking. The feedback was mostly very good: many said that they now had a vocabulary to describe and work with the behaviours they experience at work; a few people found subtle clarifications of problems they'd been experiencing; one person found many reasons to be happier with his current job.
So thanks to Joseph and Ben for travelling to Edinburgh to teach. And, oh yes, pat on my back for getting them here.
Estimation
I'be been meaning to repy to Anthony's comment on estimation. I said that you need to estimate the tasks and add them up to come up with an estimate with a story. Anthony suggests that that "yesterday's weather" is a better tool for estimation.
Correctives ("yesterday's weather" \ load factors) are something that you apply to an estimate, and yes they are good tools. You need to come up with an estimate to correct in the first place, and adding up tasks works for me. It has the benefit of helping to track progress while working on the story.
"When do you think you'll be finished?"
"Well I have 4 hours estimated left, but it has taken me six hours to get through the previous four......"
Strange day
I appear to have just thought up Steve Pavlina.
Update: Correction, you appear to have just thought up Steve Pavlina. Why would you do that? You wierdo.
Goodhart's Law and The Law
Underestimation
Still do it. Should know better, but I still do it. "Yep, I should get that finished by the end of the day."
Let's see I'll need to write Fixtures for those tests - get something passing - extract some stuff out into production. Oh and there's those couple of edge cases. Should be finished by lunchtime; I'll say end of the day to be sure.
Idiot. You need to estimate tasks and add up the estimates. It's not difficult you lazy git. Slap on back of head.
Update: after spending two minutes on a proper estimation I have 9 hours left on the story. I've already spent a day. Slap 2, coming up.
Yahoo, Google, China, confusion, and folklore
News of Google censoring search results for China hit the headlines about the same time as that of Yahoo being implicated in jailing Chinese writers.
I've lost count of the number of people who have brought up in conversation that "Google has been shopping dissidents to the Chinese authorities".
Interesting, isn't it?
Rails' Test Generation
A few weeks ago Alan Francis suggested that
The sample test case that Rails generates for models and controllers (assert true) should be created as a failure (assert false).
My badly worded comment was misunderstood. It's not how generic the test is that bothers me; I simply disagree. If rails generated broken production code then a failing test would be better. But when (for instance) you generate a model, you get a perfectly working ActiveRecord that
- works
- has ActiveRecord functionality is part of the framework and tested
- you may not want to change for a while
Under these circumstances a failing test would just be annoying. Start adding failing tests when you need to add functionality.
![Contact email to pwjobs [[ at ]] merecomplexities.com](email.gif)
