Thursday, December 27, 2007

How to reply to a FreeCycle offer

Freecycle is a wonderful way to help save the planet. It's a very simple idea - a mailing list for people in your area to give away unwanted things (or ask for things that people might want to give away). We're having a premature spring clean this month because we're moving house. So we're listing loads of things, and we've had loads of replies. Some are fast and terse, some are polite and thoughtful. If you want to be the person to collect the goods, here's the best way to ask for something:
  • Greet the person who posted the message. It's only polite. I find that the word "Hello" helps. Or the abbreviation "Hi".
  • Tell them that you would be interested in the item (without presuming
    that they will give it to you).
  • Tell them how it would improve your life, or someone else's life.
  • Don't abbreviate your message. Use full words.
  • Make sure that your email software is set up to use your full name. I'd
    much rather agree to pass something on to a named person, instead of
  • Thank the person for their time.

Some may argue that speed is of the essence, and that the fastest email
will win. Maybe. But unless you're sat there watching the emails roll
in, you're probably not the first to reply, anyhow.

Besides: Freecycle is about reducing consumerism and landfill use. Which email approach do you think is most appropriate?

Wednesday, December 19, 2007

My daughter isn't even 5 yet and she draws mind maps

Sometimes when I feel the need to get an overview of something, I draw a mind map. Yesterday I announced my intention to do just that when Abby said: "I can do mind maps!". She proceeded to do this animal themed map in my notebook.

I feel very proud and old, at the same time. I was 20 when I first read about mind maps.

Wednesday, December 05, 2007

Sunday, November 25, 2007

XP Day 2007: Brilliant!

Presenting an experience report while recovering from a bout of stomach bug: Interesting. I think I did well considering. The response was positive, with two pieces of negative or neutral feedback, but 17 positive. I presented this talk at Agile 2007 this year with my friends Shane and Rolf. We assumed that was it (we all binned our talk notes, which didn't help me), until Angela Martin kindly suggested that we submit it for this conference.

Top tip: if you present 3 person report without the other two people, rewrite slides so you know what it's really on about.

I'd never been to an XP Day before; I was very pleasantly surprised by the lovely people and the great sessions. Highlights for me were:
  • Catching up with former colleagues, people from CITCON, and other conferences
  • Being prepared to argue about Non Functional Requirements in Sally Ann Freudenberg's fishbowl, and having Nat Pryce and Keith Braithwaite argue most of what I wanted to say anyway.
  • Duncan Pierce and Rachel Davies' standing-room-only session 'Cognitive Bias in Decision-making'
  • The final session for the second day of the developer track was Steve Freeman's panel: 'Have we lost our Mojo?'. It was great to see so many notable people debating the state of the Agile community.
In summary: It's well worth attending.

I think the Mojo is behind the cushions on the sofa, anyhow.

Wednesday, November 14, 2007

I'm presenting at XP Day London next week

I'm presenting an experience report called "Large Build Teams: Help or Hindrance?" at XP Day London this Monday. Looking forward to it.

Friday, November 09, 2007

CruiseControl Best Practices - part 3 in English and Chinese

The third installment of my series, "CruiseControl Enterprise Best Practices" is available in English and Chinese. Thanks as usual to John, who publishes the ThoughtWorks Studios blog posts for us, and Guanglei for the Chinese translation.

Also, thanks to Chris who pointed out the WTF in my tests for validator code.

Monday, October 22, 2007

My CruiseControl blog posts, in Chinese

My colleague in Beijing, Guanglei Li has very kindly translated my first two blog posts for ThoughtWorks studios into Chinese:

Thank you Guanglei.

I was hoping to complete the third post at CITCON Europe this weekend, but it's not quite finished. More on that soon as well.

Monday, October 01, 2007

More build pipeline discussions at InfoQ

Amr Elssamadisy at InfoQ wrote up the conversation that Simon Stewart and I have been having about the Build Pipeline, here. Thanks Amr!

Monday, September 24, 2007

CruiseControl best practices on the ThoughtWorks Studios blog

I'm writing a series of best practices for CruiseControl Enterprise on the ThoughtWorks Studios blog.

Posts #1 and #2 have been published already.

Sunday, September 16, 2007

bike thieves: scum sucking leeches

Ant and Smartfrog maintainer (and keen cyclist ) Steve Loughran had his bike stolen in Bristol today.

Charmingly they knocked over his 5 year old son while nicking it. The full story is on his blog. If you live in or near Bristol, England (or even if you don't), please have a look. You just might help recover it.

Wednesday, September 12, 2007

Damn you, Obsolescence!

My first real job was in a computer rental company. I used to service and install Apple MacIntosh computers. I'm in my 30's now and I was 19 then. The only thing that the me of 1992 would recognise in an Apple Store in 2007 would be the logo. Perhaps that's why I am so obsessed with ancient Mac systems now - perhaps it's a way of holding onto my past identity as someone who loved working on Apple computers. I'll save that one for therapy.

Anyway, right now I have a leaky garage full of Apple Mac parts that I need to shift before winter. I've decided to stick with one ancient Mac and find a new home for the rest. It drives me mad to see people making aquariums out of working computers that could still be used. So if you know anybody who tinkers with old Apple kit, please send them the link below. I don't normally pimp my Ebay auctions on my blog, but in this case my motivation is to keep some working computer parts out of landfill.

Update: A very nice man collected the whole pile of Mac gear on Friday. Now I need to freecycle the PC bits ...

Saturday, September 01, 2007

published at last

I presented an experience report at Agile 2007 last month with my colleagues Shane Duan and Rolf Russell.

The full paper is available from the Agile 2007 website:

I also helped present a workshop on Continuous Integration with Tom Sulston and Paul Julius. Photos here:

Friday, August 03, 2007

The cost of change for build and deploy

Deploying software in Agile projects is often considered a black art or a thankless task.

Flattening the cost of change ...

We've pretty much always known that in waterfall projects, later changes cost a lot more than early changes. Agile methodologies attempt to flatten the cost of change by the use of practises such as testing, continuous integration, iterative developmet, collective code ownership and early deployment. This is successful in a majority of Agile development projects; and we continue to write tools and frameworks to allow us to write software faster and cheaper. This is all good and I wouldn't want to work any other way.

... for everything?

The software project that I am working on is delivering well software when we plan to deliver it: we have a large team turning out Java applications that are delivering value to the business.

So why is deployment such a poor cousin to the code that it deploys? Almost every project I have worked on has ended up with a deployment script that is a polyglot of Unix shell script commands. I don't attribute the problem to the choice of scripting language; such scripts make computer systems around the world run, and will continue to do so for years to come. What I want to explore is how we deploy software quickly without creating a deployment script that nobody wants to touch.

The safety net

Refactoring poor code can be challenging, but it's certainly possible to do so without breaking the build. Chances are that you'll be able to ensure that at least your new code has test coverage to give you some confidence. You can always fall back on the debugger in your IDE. When you do break the build, you'll most likely be able to use the feedback to resolve the issue.

Compare this activity to changing build and release scripts. You don't often have test coverage for what you are doing in this world. Your scripts may not be executed until days later, perhaps more.

Finding out that every released version of code since last week has been broken by your change could be considered a gumption trap.

The 1990's called. They want their deployment system back.

The cost of change, which we have done a great job of flattening in software projects comes back with a vengeance here. Once we leave the IDE , we seem to give up our agile practises. We cheerfully deploy fully tested code with an untested deployment system.

We seem to confuse several activities on software projects: build, deploy and systems administration.

Because deployment is the area where code artifacts meet the systems run by the operations people, it makes sense in a narrow way to have those people own the deployment scripts and process. But to do that overlooks the fact that developers can bring a lot to the deployment process. I'd much rather see collaboration between the developers, who bring coding expertise and the systems people, who know a thing or two about how to deploy applications. In my experience, throwing deployment entirely over the wall leads to a less than optimal process and developers who know nothing about how the code that they write gets run.

All very depressing. what can we do?

Consider your options for deployment systems

At the very least, consider writing your deployment system in a language that is easily testable. Python and Ruby come to mind. You may also be able to adopt a framework like SmartFrog or Capistrano, rather than rolling your own.

Exercise the production deployment process in Continuous Integration

We rehearse plays, weddings and deployments. But are we rehearsing the same thing that we perform on the night? Not on some projects: we have seen farce being rehearsed during development, and then drama being rehearsed in the deployments to test environments. Many projects suffer from a scarcity of test environments. Use your time on them testing software rather than debugging deployments.

Think up front about your requirements
Spend some time at the whiteboard, thinking about your requirements for deployment, and what might come down the road. If you have time to implement them and you can, do it. This goes against the grain of Agile software projects, but when you don't have the benefit of refactoring, or other nifty practises, you'll constantly be playing catch-up.

Monday, July 30, 2007

The pipeline of doom

Simon wrote recently about the Build Pipeline. His enthusiasm for the technique is infectious, but I have to add a note of caution. The big idea is to reduce the feedback cycle for developers ("the unit and db tests passed on CruiseControl, our checkin looks okay") while still allowing slower automated acceptance or regression tests to run afterward. Of course, the entire team needs to treat the second build with as much reverence as the first.

I haven't always found that to be the case. So I wouldn't recommend this technique unless the team already has enough discipline to keep a Continuous Integration build green, for starters.

The other aspect of the pipeline that I find troubling is this: by not forcing the developers to sit through the functional tests before they check in their code, you prevent their fantastic brains from reflecting on improving them. If people are feeling the pain of running them, they have a good motivation to fix them. Those tests ought to provide the biggest bang for your buck: unless you're careful you could be running poor tests dozens of times a day.

Don't simply push those tests down the pipeline, but fix them where you can, and keep the feedback loop as fast as you can for the entire team. After all, there's no silver bullet.

Sunday, July 08, 2007

Ha ha! Take that, ${temp.dir}!

I don't often celebrate removing weird things from the Ant build on projects - it's part of my job. But this one was special. ${temp.dir} used to point to the /tmp directory on the build servers. Several targets would read or write artifacts into that directory. ${temp.dir} had probably had a very simple job when it was conceived, but over time things had been twisted to do more with it. It bugged me.

Over some weeks it had been a part-time hobby of mine to make small changes to the build so that I could finally remove ${temp.dir}. And recently I actually did remove it. I find that by finding something that irritates me, and reflecting on a way to remove it, I end up simplifying things in the process. I often end up breaking things if I jump in and fix it; so I force myself to make small steps in fixing the problem until the day comes that I can remove that-which-bugs-me with confidence. This usually has the happy side effect of making the build more robust and easier to understand.

Now I'm looking at cruise-properties.xml. It'll have to go.

Tuesday, May 29, 2007

This book will change your deployments

I've been doing build and deployment on Java projects for ThoughtWorks for 3 years. I've seen things. I've asked a lot of people to fix the build. I've dug into build.xml files, shell scripts and worse to deploy code. What I haven't done is read many books that gave much insight into the craft of the buildmaster.

That may change soon. Steve Loughran and Erik Hatcher's new book Ant in Action is available for early access now: the printed edition will be here soon. It's the sequel to their 2003 book Java Development with Ant. Steve kindly let me see the chapter on deployment; they've managed to distill some of the key lessons that you painfully learn about deployment into a single chapter. It's worth buying the book for Chapter 16 alone.

Thursday, May 17, 2007

We did it ...

... and rode over 30 miles in the soaking rain. It was raining when we left the house, it rained while we rode slowly to the starting point, and it rained while we waited to get our control cards stamped and go. The route went south from Woking, down the Surrey Cycleway, and then around a back-roads course past the towns of Ripley and Send. There were three checkpoints along the course which served drinks and doughnuts (snack of champions?).

One of the checkpoints was at HMP Send which is surrounded by beautiful woodlands; most of the route was very scenic, and we got to ride (briefly) past Woking Palace and the ruins of Newark Priory at Pyrford. There seemed to be thousands of riders of all ages and abilities. We had intended to keep a slow and steady pace, but there was a constant need to overtake or be overtaken. Lesley and I did try to ride abreast where we could, but with a fun ride and 2 races on that weekend, there were many bikes on the road.

It was great fun and we raised some money for a worthwhile cause. I'd never done that before, and I think I'm going to bore you with it all again in 2008. Post-ride photo at the justgiving site:

Monday, May 07, 2007

Woking Bikeathon Training

Our training for the Woking Bikeathon has been less than adequate. I cycle a few miles a day to work, and Lesley cycles where she can. In a perfect world we would train several times a week. Last weekend we cycled about 25km from Woking to Virginia Water and back.

On Saturday we drove the route to get acquainted with the course - it's mercifully flat and very pleasant with plenty of shade in the country lanes. Actually seeing the course was a shock; it's longer than it looks. On Sunday I rode less than a third of the course (from Woking to Ripley, and back through Send). I didn't have time to ride much more, but I did learn that I need to make a few more adjustments to my bike so I can comfortably do the ride.

I hope to have my knees intact after the ride, so I will be focussing on keeping a steady pace throughout the course. I'll be very happy if we raise money for the Leukaemia Research charity, enjoy the ride, and can physically ride home afterwards. If you want to sponsor us or see who has already, click here.

Thursday, April 26, 2007

The 2007 Woking Bikeathon

Lesley and I are riding 30 miles in the Woking Bikeathon on May 13 to raise money for Leukaemia Research.

It's a good cause and you can sponsor us here if you like. Thank you!

Sunday, March 25, 2007

Slides from my UKUUG presentation online ...

... here (click on "Agile Systems Administration"). The talk was fine. 25-30 people came, which was enough for me to feel good about attendance, and still keep vaguely cool.

It turned into a general discussion at the end with a particular focus on Puppet. One point I wanted to make now that everyone has left the room (and the conference) is that you don't need to know Ruby to use Puppet. It has a very simple declarative syntax that you use to tell Puppet what state you want your system to be in. And you can call shell scripts if you really want to ...

Monday, March 12, 2007

CruiseControl.rb: the newest Cruise Control

There are 3 CruiseControls as of today. Java, .NET, and now Ruby. The newest one looks fantastic and is very simple.

There's a 5 minute movie of the install here:

and more info on the site here:

Here's the features:

* Can be installed in 10 minutes.

* Works out of the box with a regular Ruby or Ruby on Rails project. No configuration necessary.

* Web-based dashboard, convenient, useful and pretty.

* When a build is broken or fixed, notifies users via email, instant messaging or CCTray.

* RSS feed to track the build status of your favourite projects.

* Jump to the code causing a build error in one click.

* Displays custom build artifacts. No configuration necessary.

* Can interoperate with any build tool that can be invoked through command line and returns a non-zero exit code if the build fails. Like:
o nant
o ant
o etc…

* Extendable through builder plugins, custom build schedulers and other configuration options.

* Infinitely hackable thanks to publicly available source code and Ruby open classes.

* Free as in “free beer”.

Sunday, March 04, 2007

Infrastructure Patterns

Chris and I talked about applying patterns to infrastructure some time ago - developers use patterns in their work to identify common uh, patterns in code and identify those. Once I joined TW and saw developers using this common vocabulary to describe code, I was sold on the idea. So can we do the same thing in the world of infrastructure?

The answer would seem to be "yes" because Bruce Robertson and Velentin Sribar wrote this book about identifying patterns, and how that leads the infrastructure architect to design infrastrutures that allow for adaptability. It's about time too. I've refactored infrastructure and I usually bark my knuckles in the rack.

A keyproblem identified in the book is "stovepipe" infrastructures - where you may have many applications that have seperate but similar infrastruture, sitting side by side in the same datacenter. Those who tend towards risk aversion might consider that a good thing - if your NFS server falls over, it only takes out one application, rather than 4. But if you're managing 4 NFS servers, how much does that cost you to operate? And do you manage to get any economies of scale?

Anyway, 9 infrastructure patterns pop out of the book. It's a damn fine start.

What I wonder is this: The patterns that we use in code are sometimes named after concrete (infrastructural) things: Proxy, Repository. So when we deal with concrete, actual proxy servers and repositories, can we try and adapt those patterns for this context? Should we make a concrete proxy pattern to describe the Squid proxy, web server plugins for application servers, or other infrastructure that does a proxying job?

Or perhaps a that concrete object is simply a part of a larger infrastructure pattern, like "N-tier transact" from the book? What do you think?

Monday, January 08, 2007

Presenting at the UKUUG Sping Conference, Manchester, UK

I'm giving a talk on Systems Administration in an Agile context at the UK Unix User's Group Spring Conference.

Looking forward to it.Link