Liz Keogh's blog

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.