Technology has changed the world. It’s changed the way we live and it’s changed the way we interact with our friends, family and colleagues. When I was a young boy my father would check a road map before setting off for a long drive. These days we simply turn on the SatNav and let it guide us (sometimes in the wrong direction). When you think back it’s amazing how quickly we have given over so many decisions, so many tasks to technology in its many forms. We’ve allowed technology in and we now rely on it more and more.

This blog isn’t going to become some massive rant on how the population of the earth should be worried. Nor is it an attempt to scare anyone into believing that a Terminator style Skynet apocolypse is about to hit us. It is, in fact, simply a diary of how I’ve become affected by technology, how I’ve become reliant on it and how, quite often, without technology I’d be lost.

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