Thoughts from a Thirsty Bear

Anyone who reads my articles will already be familiar with the quote I use at the top of each page - " It is not the strongest of the species that survives, nor the most intelligent, but the one most responsive to change. ". For me, this cuts to the very heart of agile and lean techniques. Being successful is not about being powerful, or even knowledgeable in the traditional sense, but about being adaptable and smart. Way back in June an anonymous poster pointed out that the quote was misattributed to Charles Darwin. To my shame, I sat on the comment until I had the time and patience to research the correct answer. I can now confirm that you were absolutely correct, Mr Anonymous. It was misattributed. The quote most likely comes from the writings of Leon C. Megginson, Professor of Management and Marketing at Louisiana State University at Baton Rouge. The quote is a paraphrasing of Darwin. I won't bore everyone with details, but here are links to the corroborating ar

I've been fairly quiet recently for various reasons, but rumours of my online demise have been grossly exaggerated. The brief hiatus has given me time to think about several new articles that are now in the pipeline, so watch this space.

All change! I am in the process of migrating this blog to another account. For anyone following via my Blogger profile, I am now over here .

Oh dear. It would appear that some people reading this blog and Twitter feed believe that I am writing specifically about them. Naturally, this makes them a little sensitive to the criticisms that I sometimes level at the industry and the comments/observations I make. Let me reassure everyone that the articles I write generally don't relate to any one client, or incident, or person, or project. There really would be little point in writing about anything that is only specific to one project; to be fair it would be deathly dull, and irrelevant to everyone else. Even in the rare case when there is a particularly interesting success or failure story, I ensure that names are changed, and generally wait a while as well before publishing to anonymise the problem and protect the guilty. And remember I have had people I have never worked with before accuse me (albeit lightheartedly) of spying on their project, so some observations must be common across multiple projects. Sometimes I pu

Once upon a time, in a galaxy far, far away, I spent several happy years working for the legendary Acorn Computers and their near mythical set-top box subsidiary, Online Media . We did some seriously cool, groundbreaking stuff there, including being (arguably) the first to stream video over internet protocols. All the computers ran on RiscOS , a homegrown, lightweight, adaptable operating system for ARM processors. Alas this time came to an end, and Acorn disappeared, but their legacy lived on. RiscOS  carried on, supported by various companies. I had mostly forgotten about it until now. An old colleague recently mentioned that in 2006 a group of ex-Acornites started a new company, RiscOS Open Limited (ROOL), dedicated to maintaining the operating system and take it forward. The OS is still available, and supported. So do take a look, and if you have an interest in RiscOS then do consider helping them out.

By now we should all be aware of the "broken window effect", not least because there is now concrete evidence that it exists. As a reminder, the "broken window effect" is that subtle, damaging change in attitude that causes perfectly normal, law abiding, sane people to break social norms if they see others doing the same thing. People are more likely to litter an untidy, graffitied street than a clean one. They are more likely to damage a car that has already been damaged. And they are more likely to write badly structured code and cut corners in a codebase if there is evidence of others doing the same thing. But I think there is an insidious, darker side to this. Accepting broken windows for too long desensitises and deskills your team . What happens is this. The bad behaviours that happen due to being surrounded by the broken windows - broken builds, releasing untested code, mend-and-make-do workstations and so on - become the new social norms. People get used

As regulars will have noted I'm having a bit of a spring clean of the blog layout - new title, template etc. Feedback and reports of weirdness welcome - contact me here .

It’s always a bit of a shock when you get unexpected feedback, especially from someone who you have known for a while. It happened to me quite recently with a conversation that went something like this: Friend : “ You’re dead against agile tools, aren’t you? ”  Me (confused): “ Erm...not exactly.... ”  Friend : “ But didn’t you persuade several teams in < major co > to throw out < agile tool vendor > the other year? ”  Me : “ Not me. The team simply decided that the tools were not providing value to the way they worked... ” However, thinking back I think I can see how some people have formed the misconception that I think agile tools are Satan’s Spawn, and should be eradicated at every opportunity in favour of a simple pen, 5x3 cards and at a push an Excel spreadsheet. Reality, as always, is a little different.... My view is that many teams prematurely select an “agile tool” before they know what they need. Teams (and departments, and companies) are like k

Via various convoluted routes: Become a Certified Agile Software Specialist! Update : the link is now cobwebbed, but if you did the original then please get in touch! Update 2: It's back! FTW! Update 3 : the link has disappeared again. Boo!

Following a fairly public spat and veiled threats over trademarks by Oracle, the Hudson CI server has been renamed to Jenkins . OK, technically Jenkins is a branch of the Hudson code, so it's more like Hudkins or Jenson . Oracle (sorry, " the Java community ") will continue to develop the Hudson trunk, however the branch appears to have the blessing of the core Hudson Jenkins development team and the community (the vote to fork appears to have been virtually unanimous ). If it looks like a duck & quacks like a duck....then the parent might just start resembling a dodo . I'd like to wish the Jenkins team good luck. I've used Hudson to great effect many times, and look forward to the future improvements with the new project butler.

I'll be attending the Lean Software & Systems Conference in Long Beach, California 3-6 May. I'm not in the States very often any more, so make the most of it. Come over and introduce yourself!

Something is happening in the Test First world. There appears to be growing use of " Behavioural Driven Design " (BDD). That is, the test names in test classes are becoming sentences describing what the class should do, eg testFailsForDuplicateCustomers() . In my opinion this trend is damaging the effectiveness of Test First Design in the field. Don't get me wrong - I think the fundamental idea behind BDD is sound. But I am finding that this kind of naming approach for unit tests is seriously detracting from the "code is the documentation" ideal. If you have a class with method " X ", you should expect a test method " testX " that defines the method's contract. If the method's contract is more complex, you might expect to see a set of methods like " testX_NullInput " etc. This approach documents the class pretty damned well in my experience. Now image the same class being tested by something like " testFailsIfC