juliansimpson.org

Last chance to sponsor us before the Woking bikeathon.

2008-05-08T22:42:00.002+01:00

Leukemia is horrid. Riding bikes is good. That's why we are riding in the 2008 Woking Bikeathon for Leukaemia Research. More info: Link

Scaling up CruiseControl ...

2008-04-21T18:22:00.002+01:00

... is my latest CruiseControl best practice post. In English and Chinese.

Do you have a Mac OS 7 install CD or disks cluttering up your office?

2008-04-07T20:34:00.003+01:00

I'm going to either:

- give away my beloved Apple MacIntosh SE/30, or
- make the thing work.

I'm looking for a copy of Mac OS 7 so I can make it boot. With the 80Mb hard disk that I used to run my business on in 1996, an external SCSI CD-RW drive and a little luck, I think I stand a decent chance. Drop me a comment if you know where I might get a copy. Thanks.

Update: It looks like I'll need to resurrect the x86 machine in my cupboard, burn some floppies to boot from, and then boot up the Mac. I should have been doing this on those long winter nights ...

Looking for the CruiseControl validator?

2008-04-01T22:55:00.003+01:00

Short Answer: Sorry about that. You can find it on Build Doctor.

Longer Answer: After my hosting firm destroyed my server, I set up a blog on blogger to keep going with. Tonight I decided to have a spring clean and get rid of my single static HTML site at www.juliansimpson.org, and redirect the blogger blog to that address. Things might be weird for a day or so.

Riding 30 miles for charity again

2008-03-31T22:47:00.001+01:00

We're riding the annual Woking bikathon in support of Lukaemia Research, on May 11. Link

My latest CruiseControl Post in English and Chinese

2008-03-08T10:52:00.002Z

English version on www.build-doctor.com: Link

Chinese version on blogjava.net: Link

I'm glad that's over

2008-03-02T22:17:00.002Z

We moved house in the latter part of January. I was looking forward to getting an office again. My last office was converted into a small child's bedroom after a prospective buyer of our old house was heard to mention "There's nothing but computers in there!". Abby was so happy with her hastily arranged new bedroom that I couldn't bring myself to kick her out again.

So for the first time in about 3 years, we have an office. It still looks like a bomb hit it, but I have been able to do some blogging. Now that the broadband is alive again. We changed phone and broadband providers with the house move. A week with no BT line. 40 days and 40 nights (literally) with no broadband. Thank you, as yet unnamed telco. It's amazing how inadequate dialup is. Especially when you've just had to hand back your shiny new Mac Book Pro to your old employers and need to set up a new computer.

I can sympathize with Warren Ellis.

This weekend I did manage to upload a new CruiseControl Best Practices post. I'm publishing on Build Doctor at least in the interim. I'm not sure what the deal is for ex-ThoughtWorkers posting on the ThoughtWorks studios blog. There's another in the pipeline, too. I also finished a couple of other new posts for build-doctor.com as well.

Goodbye, ThoughtWorks

2008-02-20T14:07:00.002Z

This is my last afternoon as a ThoughtWorker. After 7 major projects in 3 countries, I'm calling it a day.

It's a difficult decision: I have learned so much about people and technology since I started nearly 4 years ago. Especially about people.

In my career so far, I have only worked for two or three companies where I have actually felt proud to say I worked there. ThoughtWorks is one of them. More on the new role later.

My latest CruiseControl best practice post in Chinese

2008-02-18T14:41:00.001Z

Fresh from our star translator Guanglei:

http://www.blogjava.net/chelsea/archive/2008/02/17/180326.html

CruiseControl Enterprise Best Practices, part 4

2008-01-24T13:19:00.000Z

The guys at ThoughtWorks Studios just published my fourth post on CruiseControl Enterprise Best Practises, here.

Irradiating your developers

2008-01-02T21:55:00.000Z

I recently wrote an article on building an Information Radiator for my project, here.

How to reply to a FreeCycle offer

2007-12-27T11:22:00.001Z

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
'booboo75@yahoo.co.uk'.
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?

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

2007-12-19T16:41:00.001Z

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.

build vs. deploy

2007-12-05T22:05:00.000Z

I just wrote an email on confusing Build with Deploy on my other blog:

http://www.build-doctor.com/2007/12/on-confusing-build-and-deploy.html

XP Day 2007: Brilliant!

2007-11-25T20:07:00.000Z

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.

I'm presenting at XP Day London next week

2007-11-14T10:02:00.000Z

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

CruiseControl Best Practices - part 3 in English and Chinese

2007-11-09T11:02:00.000Z

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.

My CruiseControl blog posts, in Chinese

2007-10-22T22:51:00.000+01:00

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

http://www.blogjava.net/chelsea/archive/2007/10/12/152185.html

http://www.blogjava.net/chelsea/archive/2007/10/15/153125.html

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.

More build pipeline discussions at InfoQ

2007-10-01T21:20:00.000+01:00

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

CruiseControl best practices on the ThoughtWorks Studios blog

2007-09-24T10:15:00.000+01:00

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

Posts #1 and #2 have been published already.

bike thieves: scum sucking leeches

2007-09-16T20:58:00.000+01:00

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.

Damn you, Obsolescence!

2007-09-12T22:48:00.000+01:00

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.

http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=170148891781

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

published at last

2007-09-01T16:43:00.000+01:00

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:

http://www.agile2007.org/index.php?page=sub/&id=542

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

http://www.flickr.com/photos/tags/thedailyci/

The cost of change for build and deploy

2007-08-03T22:27:00.000+01:00

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.

The pipeline of doom

2007-07-30T22:06:00.001+01:00

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.