Thoughts from a Thirsty Bear

To the optimist the glass is half full. To the pessimist the glass is half-empty. To the agilist the glass is twice as big as it needs to be....

I use Cruise Control. It’s my automated build weapon of choice. Why? For no other reason that it was the first one that I got my hands on. I (mostly) understand it, trust it and know its quirks and foibles. It also has a neat feature – it shows project metrics. These are shown as pie and scatter charts displaying successful and unsuccessful builds. Both of these provide useful indicators about the health of a given project. Taking the scatter chart first. This is a calendar with day on the X axis, and time on the Y axis. A dot is placed on a calendar every time there is a build – red for fail, blue for success. From this you can get a feel for the following: How many checkins are being done per day How successful they are How long a build stays broken Whether the Team is staying unusually late or coming in at weekends All of these are useful indicators as to how things are going in general. I look for regular checkins during standard working hours an

I am noticing a worrying trend amongst companies wanting to take advantage of the perceived benefits of the Agile Revolution – specifically the faux-agile project. These are projects that have stamped themselves as “agile” but do not adhere to even the most fundamental good practice. When you scratch the surface they do not continually build and test, nor do they actively refactor bad design out. Unit tests are at best given lip service, and coverage is low. In most cases the only nod towards anything remotely agile is the lack of unnecessary – or indeed any –­­ documentation. When asked, the excuses for the shortcomings are many and varied – “ We know the structure of the software is awful but we don’t have enough time to refactor it right now, but we will get around to it later when we have more time ” (yeah, right…), “ Our Company culture does not allow the Quality Department to be integrated into development teams ”, “ We don’t know how to implement the automated build