Liz Keogh, lunivore

I’ve started going through my Hellbound project and replacing some of the mocks I’ve been using in JBehave with real code.

This means, of course, that the functional tests which relied on the mocks for verification don’t do anything any more. In fact, the only way to test that Hellbound is working is by looking at the front-end.

I guess this is why packages like JFCUnit and Abbot were developed; to allow testers to get hold of the application guis and automate the tests. The only way to test a client-side application is by looking at the gui (or by checking output files, I guess). But by and large if the screen looks right, and the users can’t tell the difference between a back end made up of persistence layers and databases and J2EE technology, and a bunch of monkeys running round with bananas into which the data has been carefully etched, then it doesn’t really matter what the back-end is.

Hellbound is a game, so the users are happy if the game lets them play it. The system I’m actually being paid to produce is a retail till application, so the users are happy if they can sell things, and people are happy if they can buy things.

So really, the only way to test if your system works is if people are happy.

There are other ways to make people happy. I’m convinced that the secret of happiness, particularly in the kind of culture which permits retail till applications, is to look at what you’ve got and not at what everyone else has; to stop being jealous of success and wealth and start appreciating your own. So all I really need to do is convince the whole of western civilisation that there’s a better way, then it won’t really matter if my code works or not.

I have a sneaking suspicion that it might be easier to learn to write functional tests properly.

My current pair Dan and I got into a discussion about blame cultures. He told me about a meeting he was once in, in which the boss said, “We don’t want to start a blame culture.”

“Yes,” said another employee, “but it’s better than having a Teflon culture.” Dan told me that he’d worked in one place where a few employees had managed to mess things up, resulting in the project’s failure and the whole company going down the pan.

I reckon this is because some of them still had a bit of a blame culture, or at least a blame culture mentality. Blame cultures stop people communicating to one another. They stop people wanting to be involved, make people hold onto knowledge instead of sharing it (since being the only person with important knowledge prevents you from being fired) and cause people to avow responsibility for anything. The few people who do want to get involved and take responsibility invariably end up with all the blame and none of the appreciation. It’s happened to me.

“So what’s the alternative,” Dan mused, “when a few people can’t be bothered, or make mistakes? Where does the buck stop? How do you ask them, ‘Why haven’t you done this yet? Why’s this not working?'”

“You don’t,” I said. “You ask them, ‘Can I help you with that?’ It’s your project; it’s your responsibility too.”

“But how do you know when people need help?” Dan asked.

I shrugged. “Dunno. Everyone on this project just assumed I could use the help when I started. As a result, I’m not afraid to ask for help when I need it.”

So I’m learning things, and getting better, and I’m not afraid to start seemingly impossible tasks because I know that someone round here will help me and share their knowledge. Maybe there are people on projects who simply aren’t as good as others. A blame culture won’t help with that. People who aren’t good at their job are sometimes very good at hiding it.

I believe that sharing responsibility and communication is the best way to make good use of everyone, and find out how good people really are. It’s not an invasion of your privacy. Don’t think about it as “If you’ve done nothing wrong you’ve got nothing to hide*“. Think about it as “Everyone has something they can teach you – and you, too, have something you can teach.” Have courage. Be motivated. Take responsibility, and let other people see you enjoying it. Let people know that they can come to you for help without fear of blame. The worst thing that can happen is that you may find yourself in need of a new job. If it comes to that, you probably deserve one**. I did.

* The ID card scheme is, IMHO, another kind of blame culture.

**See also the White Book, Extreme Programming Explained, and my favouorite book so far, Extreme Programming Applied, which say much the same thing.

When I started here, I was secretly concerned. How could I ever hope to match my new colleagues’ motivation, let alone their technical skill? How could I find the time to mess with projects outside of work, and the passion to care about a job, as they did, beyond the 9 to 6 daily grind? I’ve always been enthusiastic and optimistic, but mostly that was just to keep me afloat in a sea of morose office robots. Even the best of the companies I’ve worked with in the past have had their share.

A month later, I’m a very different developer to the one I used to be; a neurotic bundle of wishes staring in futile desperation at my screen, smile fixed rigid in hope of some joy. Here are the important things I’ve learnt over the last month which may help those of you still stuck to survive the robot sea.

• Blame cultures are quagmires, trapping everything that comes into them and drowning even the best of developers. If there’s one thing that I could convince every company in the world to get rid of, this would be it.
• It’s worth keeping motivation and enthusiasm up, even on the darkest of projects. It keeps that all-important “passion for technology” alive, and gives you hope for the future. Without it, you become a morose office robot. With it, you can infect other people. This in retrospect, as motivation is no longer a problem.
• It’s worth asking about things you don’t understand. Your company hired you for a reason; they don’t necessarily expect you to be an expert on day one. Pretending you’re an expert and floundering through stuff isn’t as much fun as persuading people to teach you New Things. If you’re lucky enough to be an expert, please – teach the rest of us New Things.
• There’s more than one Right Way. Well, maybe that’s not true, but since even the experts debate over which is the Right Way, it’s worth getting to know a few of them. Be open to new ideas.
• Given fertile ground and some seeds on the wind, things will grow. Similarly, given the right environment, passion for work just happens. You don’t need to find time. Let it find you.
• Having said that… substituting coffee and sugar for sleep may be amusing in the short-term, but eventually you need to step away from the screen.

Oh, Lotus Notes.
I was rude to you
In December.

You ate my email.
Isn’t that revenge enough
For those words?

Don’t hang like that.
Don’t leave me with no choice but
To kill you.

I pity you.
You’ve never known what it is
To be loved.

I’m increasingly coming to believe that there’s no such thing as a bad idea. They tend to generate good ideas, or cause changes which help to generate better ideas in future. The only danger is that occasionally, bad ideas get put into practice. That’s why I’ve taken to blogging my ideas before I go ahead and accidentally plunge the whole world into fire and damnation, when all I really wanted was a faster toaster.

Behaviour-driven-design advocate Manish and I have just had a chat over IM. He’s pointed out to me that checking things after the event is just testing, whereas anticipating things before the event is design. Design is good. Bugfixing is a pain.

On the back of that discussion, I’m thinking that JBehave’s Story Runner should probably run a scenario as follows:

Given a context
Then this outcome should occur
When an event happens.

Which ties in nicely with the “should” mechanisms / language of JBehave.

I may, given the JBehave team’s permission (or without it, even, ‘cos it fixes a bug I need fixing) refactor the scenario invoker to perform the above steps, and write a scenario verifier which checks that the anticipated outcome occurs.

I still can’t check that a given method got the arguments after the event. Maybe you should be able to “store” an expected method call on a mock by a key, or some kind of id, so that you can check it afterwards? In fact, I think JBehave’s Minimock already does this… hmm…

JBehave’s Story Runner runs through scenarios as follows:

Given a context
When an event happens
Then this outcome occurs.

So you’d think it would visit these in the order “context, event, outcome”.

Unfortunately, the mocks all have to be set up before the event – so what you actually get is “context, outcome (setUp), event, outcome (verify)”.

What’s more, when you come to replace the mocks with real code, expectations in setUp become checks in verify,
eg: mockHellboundGui.expects("setVisible") before the event becomes assertTrue(swingHellboundGui.isVisible()) after the event.

The expectations are a kind of verification anyway. Wouldn’t it be great if you could set them up in verify, instead of setUp? If you could just create mocks in setUp (or even in the event, perhaps, where you use them), then add all the expectations at the end, after the methods have been called but before you call mockFoo.verify()? You wouldn’t do expects("setVisible"), you’d do expected("setVisible") instead.

This would also help with another problem I have; where the (real) Hellbound game factory creates a game, but I can’t expect the game to be passed to the arguments of any of my mocks as I didn’t have hold of it in setUp.

Unfortunately all the current mock schemes insist on you expecting a method before it gets called, or they fall over. What a pain.

Today I wrote my first TDD test (with help from my pair partner, obviously). It was fun watching it fail, then fixing it so it failed the way we expected, then fixing the code to make it pass. The code works. The test works. I feel a surge of enthusiasm now that I have a green bar, and I would like to share this special moment with you all.

Small steps.

Today I wrote my first proper Wiki page.

I did this because someone gave me a set of instructions in the form of some scribbled notes, and I realised that I’d need to write them down to make head or tail of them later. So I spent ten minutes putting them in the development Wiki, and five minutes making them legible.

Presumably the knowledge of the mystical process I’ve documented has been passed down on the project from generation to generation, with each successive wave of new developers learning from the one before. I feel like Charles Perrault; taking a thin slice of legend and trapping it in a palatable form which won’t offend young children. There are probably nuances, exceptions and warnings which changed the story with every telling. All these are now lost to posterity because you know that no one who knows the stories by heart will ever read them or add to them.

Three months from now, two young and inexperienced developers will be talking around the coffee machine. “Why did you do it that way?” one of them will say. “I don’t know,” says the other. “It’s what it said to do in the Wiki.”

With a little effort they’ll be able to track me down as the author, but I won’t know either. No one will try anything different as we all know that this way works. And thus another inexplicable procedure enters the development process; a strange tale built around a greater truth long lost in the mists of time.

Talk to your grandparents. Listen to what they say. One day they’ll leave the project for a better place, taking their wisdom with them.

The first program other than HelloWorld which I ever wrote in Java was a very simple version of Tetris. My OO design was nonexistent, but it enabled me to explore the language and trawl through the APIs. Goodness knows where the source code went. It was a while ago.

For a while I have wanted to rewrite the game, mostly to practice OO design, but the years have ticked over and I have different priorities. I can’t pair program at home without developing multiple personality syndrome, but there are other agile practices, technologies and concepts which I want to work with. JBehave is currently top of the list.

I’m a writer and a poet. The idea of being able to use natural language to develop code appeals to me immensely. I am therefore in the process of speccing out a version of Tetris called Hellbound (I hope eventually to get a GUI consisting of fallen angels and demons being dropped into a fiery pit). I want to develop the specs as I go along, using JBehave to help me determine the responsibilities of each class and to test their behaviour. This could be interesting, since JBehave is, um, a little lacking in documentation at the moment (want any help with that?). I’m hoping to practice other things such as: dependency injection, refactoring, testbehaviour driven development, etc.

Thanks to