Thoughts from a Thirsty Bear

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

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

I don’t know if anyone’s noticed, but I’m not very active on Twitter any more. No, it’s not the annoying “While you were away” pseudo-window that is keeping me away. Nor is it the Facebook-esque ‘heart’ button (WTF?). Nor is it the endless supply of advertising bots and idiots that seem to frequent the service (I have most of them filtered out)   It’s not even the regular misaddressed tweets meant for the Thirsty Bear Brewing Co in San Fransisco (fine fellows, and purveyors of fine beery comestibles that they are!) Nope. None of the above. It’s the distraction. On 5th November 2008, at 0525 (allegedly - I suspect there’s some sort of timezone shenanigans going on there…those who know me realise I am not a morning person) I wrote my first Tweet: "Trying out this Twitter thing….”) Since that date I’ve got involved in all kinds of interesting discussions, mostly around software development, and often with the Great and the Good of the agile community -...

It all started so innocuously. All I was asked to do was put some photos onto a USB stick that could be played on a TV in my local pub. Easy. JPEGs duly loaded onto the drive, plugged in...and found to be incompatible. Weird. So I checked the JPEG file format against the specification. I changed sizes, I changed encoding type.  Still not playing. Really annoying, and not a little embarrassing! Then I noticed - the TV was trying to display files with names starting with '._'. Where the hell did they come from? And the penny dropped. OSX creates all kinds of special files to work with non-HFS file systems - like the USB drive's FAT32 format. These files are part of the AppleDouble format , and don't show up if you reveal hidden files in OSX (see this excellent article on how to show/hide the hidden files ). So to get rid of them, you can either use a Windows or linux machine, or use the dot_clean command in OSX. Hopefully this will save someone some time tracking...

Aka "Absent Scrum Master Anti-Pattern" There is a question that keeps cropping up when talking to clients. It is  “How many teams can a Scrum Master lead?”.  My answer? Just the one. Let’s take a closer look at why people persist in asking this question, and try to understand better why it is generally a Bad Idea™.  When a team is running well, everyone is happy, and product is being delivered successfully iteration by iteration, feature by feature. There is comparatively little for the Scrum Master to do aside from day to day housekeeping. Everyone knows how the process works, everyone plays their part. The system chugs along and delivers. The SM appears to have a huge amount of slack, which most organisations believe is a Bad Thing - slack means they need to squeeze out more performance (read “ profit ”), in this case by giving the SM something else to do. I.e. another team. And maybe another. And another. Or other random responsibilities. Ignoring the ...

Right. I have to get this off my chest. A follow-on from my habitual coding observation in my previous article . How many people habitually write Java code like this? (Clue: I see it a lot) public class Article { private String title; private String author; private List tags; public void setTags(List tags) { this.tags = tags; } public void setAuthor(String author) { this.author = author; } public void setTitle(String title) { this.title = title; } public String getTitle() { return title; } public String getAuthor() { return author; } public List getTags() { return tags; } } Then you can create an object an use it with something like: Article article = new Article(); article.setAuthor("Cam M. Bert"); article.setTitle("French Cheeses"); article.setTags(Collections.asList("cheese", "food")); // etc etc G...

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