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).
The speed at which a rewrite project goes is often a very big factor in deciding whether or not it will be successful, and it’s often one of the most overlooked elements of a rewrite project.
Speed influences so many factors of a rewrite project it’s difficult to list them all in one article so for now we’ll approach them one at a time. In this post I’m going to look at the speed at which a rewrite might adopt new tools into their overall build process, but the same core message applies to almost every aspect of a rewrite, and I’m hoping that the title of this post indicates what I’m trying to get to…
Developers on a rewrite project should do it slowly.
There’s no better feeling in the world than coming into the office from a long weekend away to find that your Build Server has disappeared without trace.
Okay, so maybe there are better feelings in the world, but they don’t come close to the joy of finding that the database used by TeamCity saves very little other than user profiles and related settings, and that nearly all the really important stuff is saved elsewhere.
The letter below was given to me when I checked-in at the hotel in Glasgow. I’m pretty sure they mistook me for the other Phil Collins.
Inside the envelope were 8 drink vouchers. If the hotel gives 8 free drink vouchers to all it’s guests, especially those in rooms with single occupancy, then how would they ever make any money from the bar.
The last time I was “North of the Border” was when I was a wee boy of five years. Holidaying in Fife, close to where my grandfather was born, was the only place in Scotland I’d ever visited.
So not only was I overjoyed at having my session, “Rewriting Software is the biggest mistake a software company can make”, being accepted for a second time – and therefore dispelling the idea that the first acceptance at DDD9 was a bit more than a fluke – but I was also over the moon at being given the opportunity to make the journey upto Scotland.