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.

Feature branch workflows appear to be the flavour of the month for software development right now. At its simplest, features are developed in isolation on their own branch, then merged back to the trunk. More complicated variants exist, most notably Git Flow . Git is undoubtedly a powerful versioning tool. It makes branching easy and reliable, and it is truly distributed. These capabilities open up a whole range of possibilities and workflows to support different ways of working. But, as usual, the sharper the tool, the easier it is to cut yourself if you don't understand what you are doing. My problem is this. Feature branching is a very effective way of working when you have a large, distributed team. Code is not integrated with the rest of the codebase without a lot of checking. Pull requests ensure changes - often done by developers who are in other countries, and often part of a loose-knit open source development team - are reviewed by a core team before being inte

Hurrah! I have earned another piece of paper (with distinction, no less :-) )! This time for completing the excellent Functional Programming with Scala course run by Martin Odersky and Coursera. I have touched on functional programming before, back in the days when I used to write XSLT for a mashup engine, but this course really helped open my eyes to what the underlying principles are. Not to mention forcing me to reassess the level of test-driven you apply to the new techniques. Now the journey really begins!

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

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.

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

Planning Games can be a problem. Especially with large teams where it is difficult to get consensus, and also far too easy to descend into lengthy discussions where different people are in fact violently agreeing with each other (at least in terms of what size something is). What should be a simple one hour maximum meeting to scope out the relative sizing of specific business stories can turn into a Dilbert-esque four hour meeting from hell. Classic Planning Poker rules suggest using a timer to try and avoid these kinds of situations. Anyone can start a two minute timer, and at the end of the time the team must estimate. Limiting the amount of time gives a degree of pressure and focus to the discussions especially when there is disagreement. Also it limits otherwise lengthy discussions where in fact everyone now agrees on the estimate. I the past I have tried using this technique with some teams that had a tendency to get bogged down but with limited success. I have tried using a mobil