Liz Keogh's blog

So far I have successfully implemented the Zeroth Rule of Agile:

If you’re not sitting comfortably, rearrange the furniture.

There have been no squeals of dismay from the client. In fact, I don’t think anyone really looked up from their work as I pushed and shoved tables, rearranged power cords, moved filing cabinets and discovered the troves of untouched treasures behind the other filing cabinet which no one knew about.

While doing this, I remembered an incident at the first company which I joined, in which alongside my coding duties I acted as sysadmin. The MD saw me carrying a large monitor along the corridor, and decided that I needed a trolley to move such heavy items. Two trolleys were duly ordered. It helped a lot, I confess, and we were able to shift four monitors at once on the new beasts – but isn’t it strange that the other sysadmins (all male) had managed without them for years?

According to some religions, or denominations of them anyway, there’s a big fiery pit called Hell into which all the damned souls go.

According to some religions, or denominations, damned souls include everyone who’s not part of that religion or denomination.

This has some parallels with the Agile movement. Heaven is a place in which it’s fun to work, in which everyone collaborates to produce effective code that makes the customer happy, where there are parties and laughter and everyone is full of energy and enthusiasm. No one is afraid to speak their mind, everyone is humble enough to accept correction or constructive criticism and has the confidence to debate the merits of others’ ideas. Since everyone owns everything there’s no blame, no possessiveness, no hiding knowledge away to protect your job. It’s a great place to work. You get up in the morning looking forward to the day ahead, and commute into work knowing that everyone else around you feels exactly the same way.

It’s an ideal, but then so’s Heaven. There’s a lot you can do to improve your work environment. Enthusiasm and positive thought go a long way – but if you’re not part of the Agile movement then it’s probably pretty hellish where you work. It won’t be fair. It won’t be your fault. (Unlike eternal damnation, there may be something you can do about it.)

The Ancient Greeks had a place called Elysium, which was full of picturesque landscapes, roaming bands of heroes and plenty of fresh fruit. They also had a place called Tartarus, which is where our word “torture” comes from. You can guess what that was like. They also had a place in between, called Asphodel, where… well… not a lot happened, really. It was just a bit boring. Everyone wandered round as a shadow, wondering where the fun had gone.

Some denominations of Christianity also have a place between Heaven and Hell called Purgatory. It’s a place which is fairly hellish, but you get to leave after a while, once you’ve paid for your sins.

Me? I’m being moved onto the Diagnostics team for a fixed period before hopefully being moved into the Heaven of a more Agile project. On the Diagnostics team I will have the responsibility of tracking down all the customer complaints about bugs. They’ll tell me, “I clicked this button. I can’t remember what I was doing, or what the message said, but it was definitely an error.” It will then be up to me to work out from the logs what exactly it was that happened, and replicate the bug before passing my analysis onto my old team for fixing.

There are two ways that this could go. On the one hand, my old development team might have managed to produce beautiful code of such outstanding perfection that there are no bugs. In that case, my old team are in Elysium, and the diagnostics team are in Asphodel. There will be nothing to do. On the other hand, my old team’s code may be full of bugs and we’ll spend all our time desperately trying to track them down, paying for our sins. In that case, the development team are in Hell and the diagnostics team are in Purgatory. I think the reality is something in between, since the dev team isn’t as Agile as it could be but better than most projects I’ve been on in the past.

Oddly, I’m looking forward to both new experiences, having already spent some years in Hell. I think as long as I have a notebook and a pencil, I won’t be bored even in Asphodel. There’s too much going on in my head which I want to write down. If it turns out to be Purgatory, then I can have some fun firefighting.

Either way… roll on Heaven. I see the light.

At GeekNight last night, I spent a lot of time discussing JBehave’s story runner, and how it affects checkins.

When you parse a story and produce the template classes, they’re initially empty. Gradually they get filled in with mock objects. So, for instance, my Hellbound class’s main story, “As a Hellbound player, I want to play games so that I can improve my score”, starts with a scenario “Given that Hellbound is running, the game panel should appear when the game selection button is clicked.”

I mock the gui, and put a simple event handler in the Hellbound class that deals with a new game request by returning a new game report.

Next scenario: “Given the first scenario, a new shape should appear when I start the game.”

Now I need a real game, but I can manage with a mock shape factory. I need a real game factory. This is the point at which things get complicated enough to use PicoContainer. I’m still mocking stuff – the gui, and the shape stuff. I decide I need an event handling queue to manage thread issues between the gui and the engine. It doesn’t affect the story, but every class I create gets its own associated behaviour class.

Next scenario: “Given that I move the shape right, then rotate it, then drop it, then move the next shape left, then drop it, then rotate the next shape, then drop it, the line should be filled.” Well, JBehave doesn’t quite support this yet (give us time). I can start to use a real gui, though. I don’t have a gui shape component; that’s still mocked. Yet I don’t have any failing tests.

This is JBehave’s “amber bar”. Tests haven’t been written with real objects – they’re still using mocks. The story hasn’t been completed. It’s still OK to check in the code – no one else’s stuff has been broken. “That’s wrong,” one of the GeekNighters says. “You shouldn’t be able to do that. Red bar, green bar I understand… what’s with this amber bar?” The green bar is represented by a ., the red bar by F for fail, and the amber bar by M, meaning you’re still using mocks.

Well, the amber bar means that you haven’t finished implementing the story yet.

You get that in non-JBehave design too. You just don’t get to see it so clearly. Normally, the only place you keep track of how much of a design you’ve implemented is in your head, or in the number of task cards you’ve marked as complete, or in the amber bar of some kinds of XP planning software… oh, wait. Now it all makes sense.

When I started contracting, it was by accident – the company at which I had applied for permanent employment after moving to London suffered a recruitment freeze. Two six-month contracts later I had had enough of a very long commute each day (my descriptions of the Piccadilly line are still recorded for posterity, if any foreigners out there want to learn some imaginative uses of the foulest English swear words ever heard this side of the Thames). After abandoning that I did a little stint in the city. After that I remembered another company which had turned me down two years previously. Would they be interested again, now that I had more experience?

They were. I’m here.

Working in a consultancy is very different to working as a contractor. Contracting is a lonely existence. There’s no support, and it’s hard to be emotionally involved in the projects with which you’re working. You have to be responsible for your own training, and you’re never allowed to admit that you don’t know something. You have to fight for your jobs. It’s a lot of work, and not that much fun. Also, I hate doing VAT returns each quarter.

In a consultancy, it’s not you who’s being hired – it’s your firm. You’re part of a greater whole; privy to all the benefits that the company can offer you. They sort out the jobs, and tell you where to go. They support you, giving you training, advice and tutelage (ideally in the form of pairing). You’re allowed, even encouraged to admit that there are gaps in your knowledge base, and although you’re still responsible for your own motivation, the opportunities are provided for you. If you don’t know about a certain type of architecture you can ask which book you should read. If you want to do a project on the side there are people around to help you, with no one fearing that it might detract from your day job. You have colleagues, fellow employees, lunchtime companions, even friends.

However, the biggest difference is in your reputation.

As a contractor, you’re hired to do a job. It’s never been part of my contract to point out that the customer might be wrong – my feeble suggestions in the past that “there might be a different way” have been summarily dismissed. You have the weight of one voice, and not always a well-respected voice at that. Permanent employees hate you because you earn more than they do, with no concept that you spend the time between contracts chewing your fingernails, worrying about the rent and trying to get your accounts together. Other contractors are too busy protecting themselves against the hatred of permanent employees to back you up, if they agree, and they don’t want to endanger their chances of a contract renewal any more than you do.

As a consultant, you’re part of a company which has often been hired in acknowledgement that the consultancy knows more than the customer does. Your opinion is respected. You can say things like, “Hey – these functional tests aren’t green-barring, and I think it’s more important to ensure that previous fixed bugs aren’t creeping back into the system than it is to fix your new ones.” You can say, “PicoContainer does what you want, and is very lightweight.” And the customer listens, because your company has made a success out of recruiting people like you. You have the weight of your company’s reputation.

That weight of reputation rests solidly on your shoulders. It’s important to carry it well.

Yesterday I tacked a quick gui harness prototype onto my copy of JBehave (seemed like an appropriate place to put it). I used a thing called a QueuedMiniMap – a cut-down map which, when you get an item by key, will wait until that item is added before returning. It can also throw a timeout exception. I added a listener to window open and close events on the AWT thread which puts or removes the windows to or from the map. I’m keying the window on title (for JFrames and Dialogs), then name, then class string, depending on which one is non-null first.

I now have a mechanism for grabbing hold of AWT / Swing windows as they open – easily adapted to grab anything asynchronously. Cute. Abbot does actually do something similar – it keeps track of all the open windows in the same way – but the method which tries to get the windows from its list just keeps looping, requesting repeatedly until it gets the window or times out (the ‘child in the back seat’ method). All I’ve done is find a way to make the child go to sleep until we arrive.

I’m sure that when I go to click the buttons on the window I’ll find out that I’ve missed something (most of Abbot’s vast functionality, for a start) – but it’s fast. Very fast. Very small.

@todo next: button clicking, text entry, window visibility, focus, make sure it works in Linux too.

(Also wondering about better ways to key the windows in the map – suggestions welcome.)

(Anyone got any tips for making Eclipse work under Debian-based Linux? It says it can’t find the blatantly present startup.jar … and where do you normally keep things like Eclipse in the filesystem? I think I could use a pointer to a suitable newbie site and a good book!)

For some reason, our functional tests fail because they time out. Screens which ought to be appearing in a timely manner aren’t visible. Buttons which are enabled when the screen is populated are still disabled when the test tries to click them. I’ve been attempting to get to the bottom of this problem with limited success.

This has prompted me to look at the way in which Abbot is getting hold of the window. As far as I can tell, when a test waits for a window to appear, Abbot loops, checking periodically (once every 10 ms) to see if it’s there, until it times out.

To me, this is the behaviour of a small, bored, annoying child sitting in the back seat of a car, asking “Are we there yet? Are we there yet? Are we there yet?” until the CPU driving is so distracted that it forgets where it was trying to go in the first place. This may have something to do with our mysterious timeouts; I’m not sure. Putting a longer wait in our test fixtures has definitely improved my chances in the fight for the green bar.

Is there a reason why Abbot was implemented this way? Is there no way to, say, attach a listener to events such as a window opening? Can Swing tell us, “Get out; we’re here,” instead of us having to ask repeatedly?

If there are no sensible reasons, and no one objects to a harness which hammers slightly less on my poor little CPU, I may give it a shot. Another optional package for JBehave, perhaps. I’ve always wanted a harness which waits for arbitrarily selected events anyway; there are plenty of threaded test scenarios in which I could use it.

I will be attending GeekNight London next week. I intend to bring my laptop, complete with some kind of working copy of JBehave and Hellbound. I think Ade wants to discuss all JUnit alternatives, including TestNG, and whether they’re ready for the mainstream yet.

If you want to find out more about JBehave and see it in action, or you just want to meet that weirdo who writes poetry about Lotus Notes, this is your opportunity.

Update:Tell us you’re coming here!

After a long discussion with Dan and other JBehave dev list members, I am reconvinced of the merits of the word “should”.

Dan’s argument went something like this:

• In an agile environment, everything is mutable. Nothing is certain.

• A test which boldly declares that something will have a certain behaviour is hard to delete. It feels as though actual functionality is being removed.
• A test which suggests that something should have a certain behaviour is open to question. Should it? If the test fails, is it because there’s a bug in the functionality, or because the required behaviour is different? Perhaps the responsibility of the class has changed. Perhaps the behaviour is no longer required at all.
• It’s easier to delete or modify “should” than it is to delete or modify “will”.
• “Should” makes you question. “Will” makes you certain. Certainty is only good when combined with accuracy, otherwise it’s false assumption.
• In an agile environment, it’s impossible to always be accurate about customer requirements (and therefore behaviour).

I think even Sam is showing signs of being convinced this time.

Last night the London office was transformed for the International Women’s Day celebrations. Candlelight, music, manicurists and masseurs. Very nice.

We were also treated to a talk by Mary Beth, a life coach who teaches people how to use their personal power – their presence, their voice and their visibility – in communication. As well as teaching us how to improve our posture, she gave us a list of six ugly words which she says lower the immune system of those who say them or hear them. Stress words. Words that don’t help. Here they are:

I thought about this for a while. Why are “should” and “ought” bad words? A test ought to pass. This code should have this behaviour. I should become an Agile Coach. “Should” isn’t a bad word – just an analytical one. Isn’t it?

Then I considered the alternatives. What if, instead of “should” or “ought to”, I use “will”?

A test will pass.
This code will have this behaviour.
I will become an Agile Coach.

Suddenly the whole world opens up. Behaviour is no longer a limit imposed on code, but a contract in which I can have confidence. My goal to become an Agile Coach is no longer an idle thought, but an intention. The word “should” assumes that failure is possible, even inevitable. If everyone here had started with the idea that “the functional tests will always pass” instead of “the functional tests should always pass” then they might still be running with a green bar today.

However, the idea that code “will” have behaviour instead of “should” have behaviour has massive implications for JBehave, which starts all designs (tests) with “should”. Using the word “should” makes people actively think about the behaviour of a class, about its responsibilities, and it makes them phrase that behaviour in English instead of Geek. Does “will” have the same effect? Thinking of my Tetris-like game, Hellbound, I get:

ShapeBehaviour.willRotateRightSuccessfullyWhenNotBlocked()
vs.
ShapeBehaviour.shouldRotateRightSuccessfullyWhenNotBlocked()

Apparently so… I can’t think of a situation where I’d be tempted to write ShapeBehaviour.willSuccessfulRightRotation() (the equivalent of my test name before JBehave came along). I prefer the first of these. I like the feeling of inevitable success which I get when I read it. It will work. It is going to happen.

Now… can I convince Dan and Damian of the same thing? Is it worth making changes like this now, while JBehave is still in its infancy? Will they yet have cause to regret letting me on the team? Do I have the word “troublemaker” on my permanent record yet?