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...