As almost all developers will know, in a commercial development team, work is handed out in the form of tickets. Each ticket, in my view, represents a single piece of work and no ticket should cross the streams (or subsystems.) ie; the ticket shouldn’t contain requirements for changes to both the code and the database, as this is, in my opinion, two separate tickets that are related to each other (or, the code ticket depends on the database ticket – see the logic?)

Up until recently we’ve been assigning tickets to devs and discussing with them which tickets are next on their list, going by priority, ticket-type etc. Whilst this worked in some cases, in others it didn’t as the priority wasn’t clear enough and developers tended to cherry pick the best tickets first, as opposed to the most important, or they hadn’t written them down or something else came up that was more important and the list was thrown out the window.

Continue reading

In June 2011 I presented two sessions at DDD South West. The first was the normal Rewriting software presentation but the second was a chance to attempt something new. At DDD Scotland I had spoken to Guy Smith-Ferrier about doing a 20/20 presentation on Build Radiators and I was thankful for being given the chance to do so at DDD South West. What I didn’t expect was that on the day, in the line-up for the lunchtime 20/20’s, right before my slot, was Gary Short and his 20/20 on Asymptotes and Algorithms.

To say that Gary pulled off his 20/20, with as much practice as you can get on a train from London to Bristol, minus the time it took to put the slides together, in an absolutely impeccable fashion, will not surprise many. He is a speaker who it is simply a joy to watch. How was I supposed to follow him? I tried, and I didn’t do quite as well.

Download the video file: Build Radiators: Hot or Not

Judge for yourselves!

For those of you who don’t know what a 20/20, or Pecha Kucha, presentation is then I would suggest a quick to trip to the Wikipedia.

Every rewrite project has opportunities in it. Opportunities to improve your development process, your build and deployment strategies, your third party tools and libraries, even our choice of language can come under scrutiny (except for when you have to move because of the language you were using!)

Continue reading

If you’re using TeamCity as your Continuous Integration tool then you will be glad to know there’s a really easy way of getting a Build Radiator set up – and it’s very a quick job too, thanks to TeamCity doing most of the hard work for you by making a status page available.

The status page contains all the information we need for a basic Build Radiator but as it stands the default status page isn’t much to look at. With the help of a bit of jQuery to apply some jiggery-pokery and a little bit of CSS we can turn the text-heavy page into a starter for your own Build Radiator.

Continue reading

I love Build Radiators. The ability to pass information to a team of developers easily and immediately is far and above one of the most important things any CI method needs to do. (Apart from manage the whole Continuous Integration model)

Ever since we plugged in the Continuous Integration tool that is TeamCity I have been totally immersed in the world of Build Radiators, otherwise known as Build Status Screens or Build Notifiers (or the big red light that flashes whenever a build fails).

Continue reading