Liz Keogh, lunivore

When I first started working with JBehave, I wrote a Tetris game. I had trouble finding Swing harnesses that didn’t depend on JUnit. So I wrote one.

JBehave 2.0 won’t include Swing support. The harness was completely independent of JBehave anyway. So, we decided that I should pull it out into its own project.

At the moment, it works by finding a named window and components. Here’s an example of how to use it:

WindowControl control = new WindowControl("my.named.frame");
control.clickButton("a.button");
control.enterText("a.textfield", "Text1");

I’ve tried to make it fast, minimal and extensible, since everyone seems to want different things from their Swing harness. If you have a request for a feature, please let me know!

A shout goes out to Szczepan for the gorgeous Mockito, which I used in the tests examples. Finally, mocks that can do Given / When / Then, instead of Given / Expect / Finish recording / When / Then go back to expectations cos you’ve forgotten what you wanted your code to do in the first place.

See lots of examples, together with Mockito beauty, here.

How people

Sometimes it’s nice to get your head down without any distractions, but beware – are you cut off from the rest of the world? No one is stopping to wait for you. Get the most important things done now, and leave yourself plenty of time to play. Other gems are buried in the sandpit.

Your tool of the month is Quicksilver.

Why people

It’s always strange when an alien to your planet turns out not only to speak your language, but to read your mind. Still, they’re here for a reason. From higher up, they can see everything you can and more – is there something beyond your horizon that you need to know about?

Your word of the month is Maelstrom.

Who people

Remember all those people you haven’t seen for a while? It’s time to look them up and drag them out of hibernation. You may find it difficult to get in touch, but persevere – perhaps they’re looking for you, too. When the storm hits, the best place to be is in the centre of everything.

Your eatery of the month is Barbeque Nation, Bangalore.

When people

The tree you’ve been tending for the past few years has finally borne fruit. Ironically this means it’s time to leave your garden behind, but don’t worry; others will learn how to tend it. Pack a few seeds, your favourite books and just go – the people you rely on won’t be far behind.

Your quote of the month is: Hearts that are delicate and kind and tongues that are neither – these make the finest company in the world..

—
*I stopped doing these because I didn’t think so many people were interested. Turns out I have some fans in India, and some comments I hadn’t read. Thank you! The Horoscope returns!

What’s my sign?

Someone told me that out there, somewhere, are people who believe that “Given, When, Then” is the only way to analyse a story. I don’t believe it’s true. Sometimes there are more concise ways to get the same information. For example:

“Refunded or replaced items should always be returned to stock, unless they’re faulty.”

That’s four separate scenarios, encapsulated quite well in a very short sentence!

So why do we emphasise Given, When and Then in BDD?

Well, we can describe the behaviour in a different way. However, when we’d like to know when we’re done, we have to use a concrete example, whether it’s automated or manually driven. The only way to know whether the above sentence holds true for our system – whether the behaviour is correct – is to actually run through all four scenarios. Until they all work, we’re not done.

So, perhaps you, the business representative or analyst, don’t like using the language of contexts, events and outcomes. However, we devs use it all the time, as do QAs. However you get the information, and however you phrase it to us, the examples that you pass on to us define the scope of the story, the detail, and the end product.

An automated example sets up some contexts, causes some events to occur, and checks for certain outcomes (and perhaps then uses the result as the basis for more events and outcomes).

A manual test does this too.

With automation, particularly, it seems that contexts, events and outcomes are frequently reused to create different scenarios. Phrasing things in a way which makes them explicit can sometimes help us to reuse code in our scenarios, making the regression test suite cleaner and easier to maintain. This makes it easy to create new examples for behaviour we haven’t coded yet, which means we know more quickly when we’re done, which means you get your system delivered faster.

If we get the wrong Givens, Whens, or Thens, or we’ve missed a couple of contexts that might lead to different outcomes, then perhaps the system we produce might behave in ways that you didn’t intend, if at all.

You don’t have to be pedantic about the language – it’s OK to balance common sense with detailed explanations, and concentrate on the unexpected and on edge-cases – but if in doubt, you may find that using examples makes things a little clearer.

You may also want to read through our examples when we’re done. Just to check.

A mother was cooking a joint of meat for her family. She cut off a large slice from the side of the joint, then put both pieces into the gravy.

“Why are you doing that?” her daughter asked.

“It helps it cook properly. That’s the way my mother always did it,” the mother replied.

“Why does it help?”

“I don’t know. Maybe I’ll ask your grandmother next time I phone her.”

So the mother phoned the grandmother. “Why do you always cut a slice of meat from the side when you cook the joint?” she asked.

“It helps it cook properly,” said the grandmother.

“But why?”

“I don’t know. It’s just the way my mother taught me to do it. Maybe we should ask her why!”

So the family went to see the elderly great-grandmother. “Why do we always cut a piece of meat from the side of the joint, before we put it in the sauce?” the mother asked.

“You still do that?” the old lady laughed. “I love you, and love that you trust in what I do, but you should find your own way to cook. I did it because it was the only way it would fit in my pot!”

(My father told me this story when I was a child; apparently it appears in “Surely you’re joking, Mr Feynman” by Richard Feynman.)

You know work is good when:

1. Your smile is infectious, even on the tube.
2. Every day you find out something new…
3. …and pass on something to someone else.
4. You wonder how you’re going to have fun, not when.
5. No tunnel is so long that you can’t see the light at the end…
6. …and you’re learning to climb hills instead of ploughing through them.
7. The team can reach agreement on anything except where to have lunch.
8. You come to work with questions, and leave with different questions.
9. Your friend asks you, “How was your day?” and really wants to know.
10. Sometimes you amaze yourself.

I wrote these ten things down back in January last year. The client I was at was difficult, and I wasn’t actually getting any of these things. It seemed like a positive way to express my frustration.

A scant eight minutes after I wrote the post, I got a phone call telling me to pack my bags. I was going to Xian. I left the difficult client behind.

Now, looking back at those ten things, it seems to me that despite the occasional off day, I have them. All of them. Better still, I’ve learnt how to keep them, even at difficult clients.

That’s why I’m revisiting this post. It’s also why, after three years at the job, I’m still proud to be a Thoughtworker. You guys rock my world.

I’m reading the book “A Mind of Its Own”, by Cordelia Fine. I sometimes find it hard to make headway with this kind of material and put it down after the first couple of chapters, but for whatever reason this one has gripped me.

It’s all about the strange tricks that the brain can play on itself, and the things that people do as a result. Particularly, we become blindsided to our own faults.

Then I came across this perfect example, in an article about Donald Trump’s plan to build a £1 million golf course being turned down by Aberdeen council, with the help of assorted committees, protesters and a fisherman:

I can’t understand how anyone could misconstrue such grace and humility. Shocking. Chalk one up for the Aberdonians.

This question has kicked around a bit at Thoughtworks lately, sparked by this article:
http://blogs.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx.

I thought I’d blog what I do, since a few bits of feedback lead me to believe I might be good at it.

I don’t refactor when…

…I spend five minutes on it and realise I’m not getting anywhere. I can always think about a more incremental approach and come back to it later.

…I don’t understand the benefit that the code provides. Sometimes it turns out that it doesn’t provide any; I usually double-check that assumption before I delete the code. I might talk to the person who wrote the code to get their ideas.

…I am technically ignorant. I might give it a go, especially if my pair knows how to help – it’s an opportunity for me to learn something new – but I’ll usually timebox it, and revert if I take too long.

…I’m under pressure of time to get something done… but it’ll be on my todo list, and I won’t ask permission to finish it off properly once the pressure’s less (and if you don’t like that, give me another reason not to do it).

…it’s hard, and I don’t need to. If it’s someone else’s code and no one’s using it, reading it or changing it, the time saved won’t pay itself back any time soon. If it’s my code, it got that way because it’s built on top of someone else’s, and I need to sort that out first. This is how tech debt arises. If it turns out that it’s holding us back, and it’s time to pay for it, then I might volunteer to be part of that pair.

…someone absolutely forbids me from doing it, notwithstanding the above. Anyone doing this is letting themselves in for my ‘told you so’ when it comes back to bite. If it’s going to take less than an hour, you might as well let me go ahead and do it anyway – we’ll spend half an hour arguing, and (even though I no longer sulk about it) I’m far less productive when you kill my spontenaiety.

I do refactor when…

…it doesn’t fall into one of the above. This includes easy refactorings that I don’t need to make. If I’ve seen it, something must have sent me there! That means the chances of someone else reading it are reasonable.

I should mention that I’ve never been forbidden from refactoring anything. I’ve seen it happen once. Two pairs both tried to use the resulting mess. The refactoring would have taken one pair two hours; the mess caused each of two pairs a full day. There were definitely some ‘told you so’ moments, which is why I think the arguments are worthwhile.

I have, in the past, made huge and significant mistakes while trying to refactor! This learning experience has helped me become better at it. Everyone should have that opportunity.

Nowadays, I rarely ask permission. I justify my time by the time it’s likely to save in the future – whether in related code, similar code or simply because people (including me) are learning from good habits. If I can’t justify the time, I don’t refactor!