Agile Software

Hoist by my own petard, part two

You’d think I’d have learned my lesson, but apparently not. While the build was finally underway last night, I noticed that my search box made the layout a bit odd when you were logged in, so moved the sign out and edit profile links alongside “Welcome your name” instead of underneath. While I was there, I recklessly changed it to “Welcome, your name” (with a comma). This time it couldn’t possibly break anything, so I checked it in and went home.

Yes, you guessed it.

sign_in 'fred', 'secret'
verify_text_present 'Welcome Fred Bloggs'

The really embarassing thing is the checkin comment though.

portal build 565 FAILED
finished at 8:10 AM on 21 June 2007 taking 4 minutes and 34 seconds

Build Changeset
Revision 565 committed by 802285285 on 2007-06-20 16:57:34
Move welcome message to same line as sign out/edit profile, to make room for search. This one will *not* break the build...
M /trunk/app/views/layouts/global.rhtml

Agile Software

Hoist by my own petard

So, this morning we had our iteration retrospective, and one of the things I brought up under “what should we do differently?” was that we seemed to be breaking the build a lot. We’d got out of the habit of always running the acceptance tests before committing even minor changes, and the build often stayed red for an hour or two while the culprit figured out what had gone wrong and fixed it. We all agreed to take more care in future.

Then this afternoon, I checked in a tiny change, affecting one RHTML file and a CSS stylesheet, just to add a search box to the top of the page layout. No code involved – what could possibly go wrong?


Build failure

That’s two thirds of our acceptance test cases failing.

Turns out we had a lot of brittle acceptance tests, which relied on just submitting the first (and only) form in the page. Two-and-a-half hours and 37 modified files later (and long after I’d intended to go home) I’d added IDs to all the submit buttons and fixed the Selenium files to click them explicitly.

That’ll teach me.


Multiple class attributes in HTML

Here’s a great tip courtesy of Trenton Moss’s Ten CSS tricks you may not know. I certainly didn’t know it, but it’s quite possible everyone else does and this post is going to make me look like an idiot. I can take it.

How many times have you ended up doing something like this?


Did you know that you can specify multiple classes on one element, just by separating them with spaces?



Agile BT Ruby Software

A step-by-step BDD example using RSpec

We’ve now got a Ruby focus group at work, and one of the first things to be set up has been a weekly programming exercise [intranet link], in the style of Ruby Quiz. It’s now week two, and the problem is slightly more complex than last week’s gentle FizzBuzz introduction. Here’s the specification:

This time, the challenge is to come up with some Ruby code that converts a positive integer to its English language
equivalent. For example:

1 => one

10 => ten

123 => one hundred and twenty three

10,456 => ten thousand four hundred and fifty six

1,234,123 => one million two hundred thirty four thousand one hundred and twenty three

The code should work from numbers 1 – 10,000,000,000 (ten billion) but if it works for bigger numbers its all good.

For an extra challenge, when the strings for the numbers for 1 – 10,000,000,000 are sorted alphabetically, which is the
first odd number in the list?

I thought it might be interesting (to me, at least!) to record the process I go through to reach the solution, rather than just sharing the finished article. I’m using a behaviour-driven approach, although the process for writing a single method obviously doesn’t touch on a lot of the wider aspects of BDD.

So here it is, warts and all (I’m writing this as I go along, so I have no idea how long this post is going to get, or whether I’ll even arrive at a solution at all!)

General nonsense

Some people have too much time on their hands

I don’t know whether there’s any camera trickery involved, but this video is pretty cool. Kind of like a DIY version of Honda’s famous Cog advert.

Agile BT Enterprise Rants Software

Software/geek symbiosis

Yesterday I was lucky enough to get the chance to attend a talk/workshop on TiddlyWiki, presented by its creator Jeremy Ruston, with quality supporting acts from JP and Doc Searls. Jeremy has just joined BT as Head of Open Source Innovation, which is pretty cool in itself.

One of the comments he made that particularly struck me was to the effect that a piece of software is a living thing, but is parasitic, requiring a ‘geek host’ to live on. Much of the value of software isn’t what it does, but what it can potentially do. Once you separate the software from its geek, it starts to die, because it can no longer adapt to changes in its environment.

I think this is something that we’re losing in the world of corporate IT.

BT General nonsense

Blast from the past

The things you find in server room cupboards!


Taking continuous integration for granted

Only a couple of years ago a source code management system, as far as I was concerned, was somewhere you checked files out of when you started development for a release, and checked them back in a month or two later. Integration was something that generally occupied the next few weeks, as everybody’s changes fought amongst themselves over who could find the most interesting ways to break stuff.

Yesterday we had a major power fault in the server room where our Subversion and CruiseControl boxes (amongst a lot of much more important stuff) lives.

It’s surprising how much of a pain it now seems not to be able to commit code as I get it working. Not to be able to integrate other people’s changes. Not to be able to check that my code passes all the acceptance tests in a controlled environment.

At least it’s not like the old days when we had to actually do all our development on the Unix server, so I can still get on with things until it’s all sorted out.

Aha! It seems that while I was typing this post, the repository has come back online.
[tags]continuous integration[/tags]


Opiniated software

DHH talking about pluralisation in Rails, in Scott Hanselman’s RailsConf interview with him and Martin Fowler:

…it was kind of a firewall. It was a firewall for aesthetics. So if you could not appreciate why we did this, why we chose to go through all of this work to get prettier code, maybe you weren’t in the state of mind that was a good fit for this community. So we tried to weed people out in some sense – if they don’t share the same cultural bias, if they don’t share the same values, then maybe they’re not a good fit for the Rails community.

It’s often said that Rails makes it very easy to Do The Right Thing, whether it’s separation of concerns, unit tests, DRY or whatever. I wonder how many people start using better practices because Rails pushes them in the right direction, or whether they choose Rails because they see the obvious evidence of good practices its philosophy and architecture.
[tags]rails,dhh,opinionated software,martin fowler,hanselminutes[/tags]


Another reason to have frequent retrospectives

Josh Evnin writes in Agile anti-pattern: Developer-focused retrospectives:

In a retrospective, however, it is important that no one group of team members is favored over others. This is harder than it may seem, especially when the developers make up more than half of the team.

The way most retrospectives I’ve been a part of have worked is some variation of the following:

  1. Individuals think of a few things that have gone well, and a few things that have gone less well over the past set time period
  2. These thoughts are put on post-it notes, then placed on a wall
  3. Individuals read all the thoughts and vote for the ones that they agree with (each person has a limited set of votes)
  4. The retrospective facilitator tallies the votes and discusses the highest vote-getters with the team, and discusses ways to fix problems and continue successes

Now, as you can tell this is a quite democratic process. The problem is, when the ratio of developers to business analysts is 4:1, you start to see the topics discussed err towards the technical.

I wonder whether concentrating on one role’s issues is also a symptom of not having retrospectives often enough.

Of course there’s a place for project or release retrospectives, but I tend to find more frequent iteration/sprint retrospectives more useful, as they give you a shorter feedback loop. As a side-effect, there are usually fewer things to add to the list after only one or two weeks, so we have time to discuss anything that gets raised, rather than having to pick the most important.