Liz Keogh, lunivore

How people

Just when you thought you had a handle on how things worked, someone changed it again. Even coffee tastes of the ashes of your defeat. Keep smiling; it’s nothing that can’t be solved with some fava beans and a nice bottle of chianti.

Your tool of the month is Console 2.00.

Why people

A problem shared isn’t a problem solved, but ask around; you may find unexpected allies on your side. Listen to their advice. They have no idea what they’re talking about, but it’ll work anyway.

Your word of the month is etymology.

Who people

Midsummer brings the usual round of parties, mayhem and magic. There’s nothing like a practical joke between friends, but this time the joke is on you. Be careful , or you could end up looking like a bit of an ass.

Your pub of the month is the Coach and Horses in Farringdon.

When people

It’s been a difficult month, but collaboration and shared ownership finally paid off. Who’d have thought it? It’s time to give in to those generous urges and reward all that hard work. After all, you deserve it.

Your quote of the month is: Quotation is a serviceable substitute for wit.

—

What’s my sign?

A great article about Agile adoption at Farm Credit Services of America, and why the people who still don’t do Agile don’t do Agile.

http://www.cio.com/article/109751

Here’s the bit I really like:

The Standish Group, which famously compiles its Chaos data on software project failures, reported in its 2006 research that just 16 percent of waterfall projects succeeded as opposed to 41 percent of agile projects. Standish Group Chairman Jim Johnson, who has been studying project failures for years, says it “boggles” his mind why companies still resist agile development. “To say that companies or CIOs are reluctant to embrace agile is like saying they wouldn’t take aspirin for a headache,” he says. “And they’re not only not taking the aspirin, they’re banging their heads against the wall and wondering why it hurts.”

A new word for me, as in:

“I reckon you can spend three weeks failing to fix that.”
“Yeah, it’s a bit of a Heisenbug.”

http://en.wikipedia.org/wiki/Unusual_software_bug

How people

A bon-mot from a stranger indicates that May will be full of irony. Striving for perfection will bring you into conflict with those who want it now, dammit! This month someone with dark hair will annoy you; a gracious response will win them round before June.

Your tool of the month is RDT.

Why people

Rising opportunities make this month look positive, but time may pass slowly if the length of your emails is anything to go by. Don’t be tempted to respond to others’ ramblings with equal lack of thought; you should try to beat their word count by at least 20%.

Your word of the month is Sesquipedality.

Who people

New-found discipline in your social life is leaving you with time on your hands. There’s plenty to do; experiments will produce results. Avoid anything with “Drink me!” on the side.

Your pub of the month is the Coach and Horses in Farringdon.

When people

A question asked in innocence suggests new ideas – but is the timing right? An opportunity to travel presents itself and this may give you space to breathe, assuming you can get a visa.

Your quote of the month is: “He who would travel happily must travel light”.

—

What’s my sign?

I find the whole Creationsim vs. Darwinism discussion very interesting. Did God create the world in a few days, or did it take billions of years?

I wrote a book once.

It was a fantasy story, and the world in which it took place was about 1,500 years old. It took 2 years for me to write. (It never got published. But…)

If I can create a world that’s 1,500 years old, using words, in 2 years, I’m pretty sure that God can create a universe that’s 13.7 billion years old, using stars and atoms and dinosaurs and people and quantum physics, in 6 days.

His plot’s probably better than mine, too.

Update: Whatever else I believe in, I believe in evolution. I’m curious as to why there’s no room for that and Genesis to both be right, which is why I wrote this. It was a deliberately short piece, intended to be thought-provoking but not very serious, and I didn’t have room to cover every single version of creationism.

I have a number of mails and comments suggesting that I should have taken into account the possibility that there is no God.

I wasn’t attempting to argue that there was. I might do that in a later post, but it wasn’t the aim of this one. So, please – enough with the mails.

Sometimes I say things that I shouldn’t.

One of the things which I (and others) have said in the past is that BDD is just an evolution of TDD.

Evolution is what happens when creatures encounter a challenge to their survival. BDD is what has happened now that developers have encountered customers. Yet it isn’t TDD that’s evolved – it’s the developers themselves.

It’s the language which they use, their understanding of delivery and value, and the way in which they use their tools to express it.

That last – the tools – has been the focus of most BDD frameworks. They help, and with enough intelligence and creative application, they can change the language of a project. I’ve heard developers talking together, and customers, overhearing them, step in. I’ve seen newcomers to projects take ownership of stories within their first week, because the code is easy enough to read and understand. I’ve watched them as they’ve argued over the meaning of names, the phrasing of test methods and the responsibilities of their classes.

Mostly, these developers use JUnit, and start all their methods testShould. Some of them have had to put up with me showing them JBehave, but it isn’t the framework itself that’s changed the way we write code. It’s a natural shift towards an evolutionary advantage; the fluidity of thought and speech that comes with expressing the behaviour and value of the system in English (for some value of English).

The evolution is from this:

The Sheep class is too big and we can’t add the functionality we need. We could split some of the code that manages its position into a SheepPositionService, then make that responsible for keeping it inside Range.min and Range.max. That would help to separate its dependency from Produce outside the Range.

to this:

Sheep are too complicated to control. We could stop them from straying if we made a fence, then they wouldn’t eat the crops in the other fields.

If you can think of your code in English, in terms of value rather than requirement, and behaviour rather than functionality, converting it to tech-speak at the lowest possible level and the last possible moment, then you too have evolved.

BDD is still nothing new – some people have been doing it for years. But the evolutionary step is now big enough, and the freakish mutation widespread enough, that it’s worth giving the species a new name.

How people tend to learn technologies as a lifestyle. They like to find new ways, rather than spending their time on something that will be easier next week. They get a kick out of producing something that nobody’s done before. They are experimenters, and live by the maxim, “Shiny things!”

Progress in a project depends on How people, because they’re the ones who can do it.

How people are most likely to be Developers. They should hang out with Why or When. A typical conversation between a How and a Who goes:

How: We should make sure that all our third-party systems are mocked out in the test environment.
Who: There’s a party?

—

Why people tend to learn a technology as an investment, if at all. They like to learn proven technologies, or find others who know them, rather than spending their time on something that will be obsolete next week. They get a kick out of producing something that somebody wants. They are pragmatists, and live by the maxim, “If it ain’t broken, don’t fix it.”

Success in a project depends on Why people, because they’re the ones who know when it’s done.

Why people are most likely to be Business Analysts, Quality Analysts or Team Leaders. They should hang out with Who or How. A typical conversation between a Why and a When goes:

Why: If our users could submit video to our site, we’d make $2,000,000.
When: Let’s buy YouTube.

—

Who people tend to learn where the good pubs are. They like to pick up business cards, rather than spending their time learning any technology themselves. They get a kick out of putting a good team together. They are conversationalists, and live by the maxim, “You have two cows…”

Project inception depends on Who people, because they can put the When people together with the Why.

Who people are most likely to be Project Managers or Upper Management. They should hang out with Why or When. A typical conversation between a Who and a How goes:

Who: There are three new people joining the team tomorrow.
How: I’ll get some more coffee.

—

When people tend not to learn, as such. They’re very good at spotting things which would be really useful, but no one actually thinks they need… yet. They get a kick out of taking risks or sharing ideas and watching them grow. They are visionaries, and live by the maxim, “Because it’s there.”

Projects – all of them – depend on When people. They have the drive, the intuition and / or the money.

When people are most likely to be Venture Capitalists or Entrepreneurs. They should hang out with Who or How. A typical conversation between a When and a Why goes:

When: It would be great if we could make a pen-sized computer that projected both the keyboard and the screen.
Why: Please don’t play World of Warcraft in bed.

I just wanted to thank you very much for everything you’ve done so far.

This is my first stint as IM.

It could have been easier than it was, but you gave me space to breathe.

You were prepared to take on stories together, even though you were new to the project.
You improved the performance, even though you had a ton of functionality to deliver.
You took responsibility for the whole, even though you were only working on a part.
You didn’t stamp on each other’s changes, even though you were all on the same pieces of code.
You never cut corners, even though you were under pressure.
You never complained, even when more requirements were added.
You made time to keep me informed, even though you were busy.
You were pragmatic, and you never lost sight of the ideal.
You met the deadline, even though some of us doubted you.

A huge Thank You, and well done!

—

Note to readers: No Team Orange members were harmed in the making of this feat, nor did any of them work silly hours. It’s not about the time they put in; it’s about the smile on our customer’s face.

And computer terminals report some gains
On the values of copper and tin
While American businessmen snap up Van Goghs
For the price of a hospital wing.

Del Amitri, “Nothing ever happens”

We use eco-friendly bulbs. Our house has double-glazing and loft insulation. We try to buy local produce. We don’t leave our TV on standby. I walk everywhere, or use public transport. I’m better at unplugging or turning off lights, monitors and phone chargers when I’m not using them. My compost bins for the garden arrived today. Aren’t I good?

Yet I’m still consuming twice my allotted slice of the Earth Pie.

Ouch.

Last night Dan and I presented JBehave 1.0.1 to the assembled masses of Thoughtworks UK.

“Seriously though,” one spectator commented, “no one really does any of this AgileDocs stuff. Who actually reads the names of tests to find out what the code ought to do?”

On a project in which the tests consistently describe the behaviour of the code, the answer is: everybody.

“Okay. But why is it always so hard to write good tests?”

1. Your tests are not actually describing the behaviour of your code

I frequently see tests which describe the behaviour of a dependency too. A dependency is anything which is used by the thing whose behaviour you’re trying to describe. eg:

The driver should stop at the zebra crossing.

vs

The driver should press the brake pedal at the zebra crossing.

The car should stop when the brake pedal is pressed.

2. Your code is wrong.

This happens a lot to me if I’m pinning down legacy code, and I’ve assumed that the method called getTheOneRing() does actually do what it says it does. If I find I’m getting a copy back instead, there’s really no point checking that it’ll melt in the fires of Mount Doom.

3. Your code has too many responsibilities.

It’s probably doing something better done in another class; think about introducing another dependency (like a Car).

4. You’re trying to mock too many classes.

See 2 and 3.

Don’t mock domain objects. Your code should interact gracefully with them, and be able to rely on their behaviour. Mocking domain objects leads to fifteen expectations per test, and gives you no better certainty that your code is behaving itself.

Don’t mock data structures (which are frequently domain objects anyway).

Split dependency classes which consist of mixed data structures and methods to manipulate the data. That way you only need to mock the manipulations. (As an example, consider the separation of Pattern Matching and Strings). Or, even better…

Use role-based interfaces to limit the scope of dependencies. Your code should perform according to its responsibilities; it should depend on roles which help it to perform those responsibilities. If a driver’s only responsibility were to pressTheBrakePedal(), then a driver would only need a Pedal, not a whole Car or even a Hydraulic Braking System.

A pattern I use sometimes

If I have a Driver that needs a Pedal, I might define it as a public inner interface of the Driver.

Adapting from a Car.Brake to a Driver.Pedal turns out to be easy, for most instances of Cars, Drivers, Brakes and Pedals – and if, later, you want to put in that super duper new parachute breaking system for jet-powered vehicles, you can do so and adapt to the Driver’s pedal requirements without changing the behaviour of the Driver.