Thoughts from a Thirsty Bear

There has been a bunch of stuff written about the “Broken Windows” effect - the way that even good people will begin to do bad things if everything else is bad around them. In areas that look badly maintained, people tend to drop more litter. Where people are obviously flouting the rules others are more likely to bend them themselves. And in software, when you are working on bad code you are more likely to write more bad code. I first stumbled across the idea in an interview with the Pragmatic Programmers , but the evidence given is fairly apocryphal. So I was pleased to find something more definite . And it does make for interesting reading. The effect is indeed real, and significant. The number of people breaking social norms when they see that others have done something similar more than doubles. It's the 'no-one will notice another little bit of mess' effect. The study quoted in the article reinforces the need to maintain a high level of hygiene in your software.

Those fine people at the Improbable Research Institute have awarded the 2010 Ig Nobel Prize for Management to Alessandro Pluchino, Andrea Rapisarda, and Cesare Garofalo of the University of Catania, Italy, for demonstrating mathematically that organizations would become more efficient if they promoted people at random.   So that's it. Maths supports what many people strongly suspected to be true for years. The Peter Principle is real . We can replace all those pointless appraisal systems with a random number generator. Read their paper here .

" We don't pair all the time, some things are so simple they don't need it ". I have lost count of the number of times I have heard this. It's undoubtedly a seductive idea. Something done multiple times that is so easy that one person can do it, without error, guaranteed. But it is in fact a very subtle process smell, one so subtle that it's easy to overlook/justify. If something is so simple that an individual can do it without error, guaranteed, it is a prime candidate for automation . Take some time and care (and pair) to free up developers so they can focus on what they're best at - things that require creative thought. Don't waste any more time on the dull and scriptable than you need to.

Everything, young padawan!

Has your manager ever walked over to you and asked when the story you're working on will be "dev complete"? Or have you ever overheard someone ask in a planning meeting "When will the product be dev complete?". Yes, I'm sure it sounds familiar. It's also one of my least favourite managementspeak phrases because it nonsensical. Let's stop for a moment and consider what's being asked. What is "development complete"? Many managers are stuck in a waterfall, sequential way of thinking. Requirements are thrown over the Chinese wall to developers, who throw it over the wall to QA and then, somehow, magically, working software appears out of the end. To them "dev complete" usually means ready to pass to QA. However the tacit implication is that it is not expected to come back again….that, well, development is complete…. The problem is that unless it's been tested, who can know whether this is the case? And if it there is a problem

Scrum Alliance has now launched its "Certified Scrum Developer" qualification. It's a seductive idea - hire people with this certification and they will have been pre-bootstrapped into an agile way of thinking and working, same as Certified Scrum Master. So why do I think it is such a bad idea? It's taken a while to work it out, but I think I finally understand why I (and some others) don't like it. It's wordology. Pure and simple. " Certificate " and " Certification " carries a whole bunch of mental baggage. Consider these two phrases: "I attended a 5 day Object Oriented Design course" "I am a Certified Object Oriented Designer" I am referring to the exact same thing - way back in the Dark Ages I did indeed go on a week long course in OOAD. They gave me a certificate at the end, presumably because I turned up and didn't snore too loudly. Yet the first phrase carries far less authority than the second. And he

We have all seen them. Aspiring boy racers who have taken an old banger and put on the trimmings of a sports car - spoilers, big noisy exhausts etc. But it doesn’t change what is under the disguise - an old vehicle, nearing the end of its useful life, but can still limp along and get the owner from A to B. Eventually. If you have an old, rusty, Ford Fiesta, you can’t just get away with painting it red and calling it a Ferrari. It is still a Fiesta. Yet it still appears that some parts of the software industry genuinely believe that they can get away with this mentality. Let me say this one more time (with feeling) - you cannot simply take a broken software development process, put some agile tools and ceremonies around it and expect it to perform like the real thing . Or to put it another way, no matter how many spoilers and exhausts you bolt on, they can never have a significant impact on the performance of something that already has the aerodynamics of a brick and the power of an as

" What are we trying to do?" "Where is the failing test?" Repeat this mantra all the while you are developing. When you pick up a story, when you start a new slice , when you rotate onto a story, when you simply feel bogged down in detail and need enlightenment. These questions leave you with nowhere to run to, nowhere to hide. And certainly no excuses.

OK, I admit it. I have played on the Dark Side, and can confirm they have some damned good cookies . Yes, I introduced kanban to the Scrum process being used by my customer..... I know there are many people interested in this technique, so here are some key questions (and answers!) that you will come across during rollout. It's not exhaustive, but hopefully it will provide a practical starting point from which you can experiment. I have assumed some knowledge of what kanban is - limited work in progress, not timeboxed etc etc. Firstly, some background. The project I was coaching consisted of three cooperating but independent teams consisting of 4-6 devs and 1 QA. There is just one Business Analyst acting as Customer for the project - Product Owner by proxy. The project used fairly standard Scrum techniques to manage progress - stories on cards, on a board, estimated using planning poker. The board consisted of swim lanes Not Started, In Progress, QA and Done. Standard stuff. Howeve

It's such a common mistake. A company claims to be "agile" (whatever that is) yet keeps the old, stale accoutrements of waterfall interviews. The developer candidate walks in, answers random questions on what can relate to extremely wide and deep subject matter, and is then judged on their ability without them ever actually demonstrating that they can do the job . Sometimes the successful candidate really can fit in with the team, sometimes not. But most importantly, good, well suited people will inevitably be dismissed as unsuitable simply because they learn the  principles and not the detail . Being a "good" software developer is no longer about memorising a spec. The ability to regurgitate arbitrary sections of a language specification parrot fashion on request, although previously useful, has been de-emphasised by the invention of radical new ways to store information. Like books. And the internet . All you need are the basic frameworks, objects and pr

The Independent has recently published an article highlighting the state of the UK Government's IT projects . Let's just say that it's not a success story: ...the total cost of Labour's 10 most notorious IT failures is equivalent to more than half of the budget for Britain's schools last year. Parliament's spending watchdog has described the projects as "fundamentally flawed" and blamed ministers for "stupendous incompetence" in managing them. Think about it. That's £ 26 billion of taxpayers' money down the drain because of " fundamentally flawed " projects and " stupendous incompetence ". Putting this into context, university funding is being cut by a mere £449 million next year - so we are cutting investment in our future, while frittering away £26 billion on avoidable failures. Epic Fail . I have already suggested that these failures are likely to have been entirely avoidable . So have others . But there nee

Just read an article containing this Japanese proverb: " If you don't know what to do, take a step forward " It's been a long time since I have read anything that sums up iterative improvement quite so well.

It's no secret, I really don't like using tools to run agile projects. More than that, in my opinion giving an inexperienced agile team an "agile tool" is like giving a toddler a chainsaw - it's going to end badly. Give me index cards, pens and a whiteboard anyday. Allan Kelly has beaten me to blogging about tools - and hit upon an interesting anecdote from Jack Kilby , inventor of the silicon chip. Basically Jack believes that the replacement of the slide rule with calculators has taken something away from engineering. Intuition. Using a tool (the calculator) distanced the engineer from needing to know what he was doing (the calculation). As someone who has used both calculator and slide rule, I tend to agree. And here lies the problem with agile tools. Using complex tools takes away a basal intuition about what you are trying to do. You lose that indefinable "connection" with the product. You might even say you lose the craftmanship . An

Those nice people at Energized Work have extended an offer for an informal chat - all for the cost of a cup of tea (or coffee, in Gus' case, although I've heard he is quite partial to green tea). So if you would like to see a presentation, or brown bag, or simply want to chat with the 2009 Gordon Pask Award winners and see what makes them tick, then drop them a line. One thing I can guarantee - you will find the meeting challenging and productive.

%%CONTENT%%