Thoughts from a Thirsty Bear

Back in 2009, a fine developer for Los Techies produced a set of mocked up motivational posters representing the SOLID principles . She was even kind enough to release them under a Creative Commons license. But as is the way of all things, internet rust has set in and the images have been unlinked from the original article during an archive exercise - but they live on throughout the internet! I have collected the images here - and would like to say " Thank you, River Lynn Bailey ". This is a great, amusing and educational resource for everyone.

A little while back I wrote an article describing how to do continuous integration . But I left out one important step that happens before any code even enters the CI pipeline. A step so important, so fundamental, so obvious  that you don’t realise it is there until it is missing. You must be able to build and test your software locally, on your developer machine. And by “test” I don’t just mean unit test level, but acceptance tests as well. I said it was obvious. But once in a while I do stumble across a project where this rule has been missed, and it leads to a world of unnecessary pain and discomfort for the team. So what happens when you cannot easily build and test anywhere apart from the pipeline? Without being able to run tests locally, the development team is effectively coding blind. They cannot know whether the code they are writing is correct. Depending on where the dysfunction is - compile, unit test or acceptance test stage - the code checked in may or may n

Working as a jack-of-all-trades agile coach, one of the biggest problems I face is the stagnation of my knowledge. If you do not stretch yourself by working with more knowledgeable people from time to time, you don't develop. You may even go backwards. Prescott's Pickle Principle summarises this as: "Cucumbers get more pickled than brine gets cucumbered" or, put another way, "A small system that tries to change a big system through long and continued contact is more likely to be changed itself" (from Jerry Weinberg's excellent Secrets of Consulting book) Much as I hate to admit it, I am that "small system". So it is healthy and fun to occasionally sit down with like-minded people, and re-baseline your knowledge. That is exactly what I did the other Saturday. I survived a dull and freezing Wimbledon to attend Jason Gorman's " Intensive TDD Workshop " (the one-day super-intensive version of this one ). I won't go i

I practice, teach and coach Test Driven techniques. Test Driven Design (i.e. using unit tests), Behaviour Driven Development, I use them all on an almost daily basis. I find them useful since they help me do my main job of delivering software. Yet once in a while I am asked  whether I could be more "pragmatic" and less "purist" over Test Driven Development and Behavioural Driven Development techniques. I always find this an odd request, especially when I have been brought in as the subject expert to teach a company, or as a lead developer with a solid grounding in these subjects. But maybe this is not obvious to some, especially those who have never used the techniques correctly - or at all. This article looks bit deeper into the request, and see why I am totally nonplussed by even the idea. Firstly, what does TDD and BDD (arguably the "pure" version of them) usually look like? To me they look like closely related cousins, which makes this brief summ