One of my favourite characters in literature is Boxer, the horse in George Orwell’s Animal Farm. The book is an allegory of the Russian revolution and its subsequent descent into Stalinism, and Boxer represents a Stakhanovite, working tirelessly for what he believes to be the greater good. Very strong and hard-working but not terribly bright, Boxer’s response to every setback on the farm is to redouble his efforts:
Boxer was the admiration of everybody. He had been a hard worker even in Jones’s time, but now he seemed more like three horses than one; there were days when the entire work of the farm seemed to rest on his mighty shoulders. From morning to night he was pushing and pulling, always at the spot where the work was hardest. He had made an arrangement with one of the cockerels to call him in the mornings half an hour earlier than anyone else, and would put in some volunteer labour at whatever seemed to be most needed, before the regular day’s work began. His answer to every problem, every setback, was “I will work harder!”–which he had adopted as his personal motto.
Sadly Boxer is not a young horse, and as the dream turns sour he works himself to the point of collapse, at which point the pigs who run the farm under the Stalinesque figure of Napoleon have him unceremoniously shipped off to the knackers’ yard.
I’m always reminded of Boxer when I see a team who appear to be trapped in a cycle of project failure and whose suggestions for improvement are to keep doing the same things, but try harder at them. The project didn’t go according to plan? Next time we’ll have an even more detailed plan. The requirements kept changing? Next time we’ll spend longer writing requirements before we start. Estimates weren’t accurate? Then we should put more effort into estimation. And so on.
Now I’m not knocking hard work or a willingness to improve, but I don’t recall ever seeing a project fail through lack of effort. If things keep going awry then it suggests there is something fundamentally wrong in the approach being taken. Perhaps in the context of the organisation requirements flux is inevitable, and a switch to a faster release cycle developing just a handful of requirements at once would help. If lack of accuracy in upfront planning and estimation is a problem then it would be better to understand and accept the limitations of such exercises, and think about ways to work around them. If code quality is persistently poor then perhaps there is an underlying architectural issue which no amount of testing will resolve. If you’re in a hole, stop digging.
Remember Boxer’s gluey fate. If it’s broke then fix it. Don’t just ‘work harder’.
Posted on April 1, 2011
0