Categories
Agile

Agile2007: Wednesday

As you may have noticed, I’m getting a little behind posting these. On the offchance that anyone’s actually reading, rest assured that I still have my scribbled notes, so they’ll be appearing here eventually.

Presenter First: TDD for Large, Complex GUIs

Scott Miller (Atomic Object)

I was torn between this session and the one on Ruby metaprogramming, but it wasn’t clear who that one was pitched at, so I decided not to risk sitting through another basic tutorial. Alkesh went to the Ruby one, and apparently it was pretty good (if I’d noticed that David Chelimsky was presenting, I probably would have gone along). Anyway, as we all know Alkesh doesn’t have a blog (actually that’s not strictly true), so you won’t be able to read about it :-)

Categories
Agile

Agile2007: Tuesday

Keynote: Reaching New Heights: Learning to Adapt is Essential

Susan Ershler

I’m not quite sure what to make of this keynote. Susan’s talk about achieving her twin goals of success in business and climbing the highest peaks on each continent (culminating in Everest) was interesting and well-presented, but came across to me as a motivational speech for business leaders, slightly tweaked to include a few agile themes. I’d have preferred to hear something more concrete from a thought leader in agile development (after all, there are a fair few of them here!)

Categories
Agile

Agile2007: Monday

The first day of the conference didn’t get started until after lunch, so we took the opportunity to go up the Washington Monument in the morning (I’ve been posting some photos from the trip to Flickr, by the way).

Most of the slides from the conference are on the Agile2007 website, so I’m not going to go into great detail about any of the sessions here (not that I would have anyway!), but just mention the things I thought were interesting enough to specifically note down. This will probably mean that things are a bit jumbled, so sorry in advance.

Categories
Agile

The simplest thing that could possibly work

But other times we’d be programming away, and we’d say, “Now, wait a second, what are we working on here?” We’d just get stuck. And if we were stuck more than a minute, I’d stop and say, “Kent, what’s the simplest thing that could possibly work?”
Ward Cunningham

Not a command: “Do the simplest thing that could possibly work!”, but a question: “What’s the simplest thing that could possibly work?”.

Once you think of something really simple that might work, think for a minute – is there an obvious reason why it definitely won’t? If not, try it, and then you’ll know. More importantly, if it didn’t, you’ll know exactly why not. Maybe it was functionally correct, but not fit for purpose – perhaps an algorithm was too slow, or an interface was too confusing or ugly to release to users. The point is, you’ve either got something you can build on, or you’ve got a concrete reason to abandon an idea, rather than a theoretical argument. If you’re lucky, it’ll turn out that the simplest thing did work, and the problem’s solved.

Too often people seem to twist this into some kind of XP Prime Directive, claiming that a particular solution is over-engineered because it wasn’t TSTTCPW. On the other side of the fence, big-picture architect types use it as a straw man to criticise agile methodologies, claiming that they ignore anything that isn’t part of TSTTCPW, leading to simplistic and unscalable solutions.

As Einstein said, “Everything should be made as simple as possible, but no simpler.”

[tags]XP, simplicity, Ward Cunningham[/tags]

Categories
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'
then_the_protocol_should_be_http
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

Categories
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?

Oops.

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.

Categories
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!)

Categories
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.

Categories
Agile

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]

Categories
Agile

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.