Liz Keogh, lunivore

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?

The term bus factor (or truck number) is one which I’ve come across before joining the wonderful world of XP.

The best definition I’ve found is here, but briefly it’s the smallest number of people whose demise at the wheels of a rogue bus (or truck) would put a project in trouble. In an ideal world, any project would be so easily understandable that even if an entire team were to disappear, another team would be able to step in and smoothly pick up from where they left off. Unfortunately things are never ideal, and our bus factor here could be better.

Bus Magnets

Fate has a way of fulfilling itself for those who taunt it. Terry Pratchett mentioned that standing “on a hilltop in a thunderstorm wearing wet copper armour and shouting ‘All gods are bastards'” wasn’t the smartest idea in the Discworld. Don’t do it on projects either, or the bus will come careening down on you when you least expect it. Here are some bus magnets I’ve seen.

• Undocumented, illegible, incomprehensible code.
• Project attrition, which reduces the number of individuals with a particular expertise.
• Blame cultures, which make people hang onto their knowledge instead of sharing it in order to protect their job.
• Blame cultures, which make people avow all knowledge of a problematic area in order to avoid having to deal with it, thus protecting their job.
• Poor working environments, which make good people (who usually have all the knowledge) leave.
• Unrealistic time constraints, which mean code is more likely to be hurried, therefore illegible and undocumented.
• Unrealistic time constraints, which mean code is more likely to stay illegible and undocumented.
• Perfectly working code. It doesn’t get talked about, so as attrition occurs, so does knowledge.

Unfortunately, attrition (or rotation) is required to stop people being bored, and working code is an important stage on the road to customer satisfaction. However, there are a couple of things which can be done to minimise or alleviate all these problems, and reduce the probability of your project being terminated by a bus.

Bus Buffers

• Write code legibly. Spend some time thinking about the wording; in comments, if you include them, and in the names of variables, methods, classes, packages and associated files.
• Be consistent in the wording between domain and code. (JBehave!)
• Say no to blame cultures. (Have I said this before?)
• Keep a happy working environment and ensure that people care about the success of their project (see XP Explained).
• Pair program! Particularly, make sure the newbies (like me) pair with the experienced people. Encourage the experienced people to treat the newbies with respect, and to have patience with them. We are the future.
• If something hasn’t been changed for a while, and seems to be working perfectly, document it. Even if it’s just a couple of lines on a Wiki. Remember to update or remove the documentation if it changes – erroneous documentation is worse than none at all.
• Be realistic about time constraints. Encourage customers to be realistic too; they don’t want to end up with shoddy code any more than you do.
• Keep people who’ve rolled off a project available for consultation where possible.

Of course, there’s one group of people whose demise would absolutely mean the end of the project – the customers. If you care about your project’s success, I guess you should care about theirs, too. It doesn’t just end with getting paid.

This post has been spawned as a result of being asked more and more for expertise I simply don’t have. Some of the best people have already left, and I’ve tripped over a couple of gaps in the knowledge pool. I guess it happens, even on projects as exciting as mine.

Less time blogging, more time pairing…

Imagine being jailed and tortured for exercising your freedom of speech.
Imagine being jailed and tortured for criticising the torturers of those who exercise their freedom of speech.
Imagine being jailed and tortured for criticising the torturers of the critical.
There are six billion people in the world, Iran. Where will you stop?

“You can’t beat the human spirit!” – Topol, “Flash Gordon”

“I disapprove of what you say, but I will defend to the death your right to say it” – Voltaire (maybe)

I didn’t get any new mail last night. Lotus Notes obviously feels sorry for me; it’s helpfully marked sixty-five random messages as “unread” so that I have something to look at this morning. The newly unread mails are scattered throughout the inbox and ten other folders. There’s no pattern that I can see in date, sender, recpient, subject or content.

Thank you, Lotus Notes.You’re so thoughtful and considerate.

Update: I have carefully marked all my messages as “read” again, but Lotus Notes is desperate for me to read them, and has just unread another ten messages for me. Perhaps I should be looking at every fifth letter or something to find the secret message it’s trying to give me? The mystery deepens…

I’ve heard a lot of things said about Linux. One of the things which I’ve heard a few times, and treated with some scepticism, is that most Linux releases are “less buggy than Windows” and crash less often too.

I’ve managed to install Ubuntu on my PC, and I reckon it’s got more bugs in it than the Amazon rainforest. It also crashes a lot – I wouldn’t ever let it borrow my car – though it’s stopped doing that so much that now I’ve moved from dial-up to Broadband. There are a number of Good Things about Ubuntu, though, which have persuaded me to stick with it through this teething period, and have encouraged me to learn more about Linux to get the most from my new found friend.

1. Gnome. The whole desktop experience is a pleasure. Especially the little GEyes, watching over me…
2. Debian’s packaging tools, which combined with Gnome allow me to click, download and install more applications than I have time to shake a stick at.
3. XMMS, which the Debian packaging thingy has mysteriously updated so that it can play MP3s.
4. Ubuntu is fast. It takes so little time to load anything up – OpenOffice, Evolution (an Outlook clone), Firefox, games… anything!
5. Gnome comes with maybe 50 addictive Solitaire card games and about 12 other simple time-wasters.
6. OpenOffice does what I actually tell it to, instead of trying to guess all the time. Plus it can read MS Word 2003 files, which most MS Word programs fail to accomplish.
7. All the information on Ubuntu is written for newbies like me. Simple step-by-step instructions for everything.
8. I can still play nethack (anyone know how to turn the graphical tiles off in X11?)

The other good thing about OpenOffice is that my novel-in-progress actually looks as though it’s printed on the pages of a book. I know I can do this in Word, but for some reason it doesn’t seem as real, and Word has never been able to keep up with my typing in page layout mode. It’s amazing how different writing looks when it’s laid out on a page. That alone makes this worth the pain.

There aren’t many occasions where arrogance is justified. If you’ve never made a mistake in your life, never taken the long way round to do something and never stepped on anyone’s toes doing it then congratulations: you are Jesus Christ, or one of the many other deified or venerated individuals with whom I am less familiar, and fully entitled to demand the slavish worship of the masses. I hereby bow down before you, you god, you.

On the other hand, if you’re just a mortal human being with all the inherent errors and sinful ways attached to that state, then you might want to stop and think what it’s like to be a different but similarly inflicted mortal. Particularly, say, someone who’s slightly unfamiliar with the subject and is seeking further discussion, someone who has unwittingly admitted a minor error whilst in search of information regarding a larger problem, or even someone who just didn’t get it the first time round.

Telling someone they’re stupid isn’t useful. Telling them why they’ve done something stupid, and giving them some hints as to how to end the stupidity, is. If you don’t have time to discuss the whys and hows then you could save even more time by refraining from criticism in the first place.

We all know this already. I do try to bear these rules in mind when making comments myself, but in that I’m also human. So are other people, and I would no doubt do well to remember that, and be gentler in my criticism.

Most recently, I paraphrased someone’s comment which, in my not-so-humble opinion, was arrogant. I did this to demonstrate their arrogance to them. The commenter wasn’t very helpful… but in hindsight I don’t think I was either. Someone else then told me (justifiably, and what a beautiful expression) to “valet park my high horse”. Why his high horse has the right to kick my high horse when it’s busy kicking someone else’s, without expecting to get kicked itself, I’m not sure… but it did make me think of the infinite cat project, and draw some interesting parallels…

Without grovelling (cos I don’t think I’ve been that bad) I’d like to extend my apologies to anyone I’ve offended lately, particularly the RSPCHH.

Lots of discussion about Design by Contract has been floating around, most of which I agree with.

Using “asserts”, etc., in code is defensive programming. Anything which checks that your classes are polite to one another is defensive; tests should pick these kind of problems up.

Wouldn’t it be nice, though, if you could easily design the things which use your DbC classes in such a way as to ensure that they adhere to the contract specified by the class that they’re using?

I’m thinking of something which sets up mock objects so that whenever a particular method call is expected and no constraint is supplied, it can look up a registered set of constraints.

So for instance, in my Tetris-clone, I would set up all my mocks of the Game interface to ensure that the size of game board created was always > 4 x 4 (the smallest square which all tetris blocks can occupy). I would do this before I actually created any Game implementations, while designing the Engine – it’s part of the Engine’s behaviour that it should never create a silly size of game.

Not sure how this would work, but it has a number of bonuses:
– it isn’t defensive programming, just another form of behaviour driven design
– it allows behaviour / test driven design to specify design by contract, before any classes exist which can actually implement asserts or any other checks
– it makes me think about the behaviour of the classes using the Engine too, since they need to behave themselves in order for the Engine to behave.

In fact, I reckon if I were to include classes called, say, “MockGame”, which mocked and added these constraints to some kind of mandatory expectation / constraint map… maybe that would work…

Let me sleep on it.

apostrophe’s
are rarely loved
they grow on tree’s
when their not shoved
out of the word’s
wots their’s by right
its not a very
pretty sight
it isnt all
they’re fault, you know,
they aint got nowhere
else to go.

—

If this resembles your lovingly crafted documentation / guide to your hobby / tutorial / code comment, you may want to enlist the help of a proof-reader. Here’s a quick guide:

1. its – like his or hers, which also have no apostrophes, means “belonging to it”.
2. it’s – like I’m, you’re, he’s, she’s, we’re and they’re, which have apostrophes for the missing letters, means “it is”.
3. apostrophe’s – means “belonging to the apostrophe”. This kind of abuse is known as “the greengrocer’s apostrophe”, as some greengrocers suffer from the mistaken belief that a carrot is capable of owning 20p.
4. would of – I think you want to use “would have”, or at worst “would’ve”. If you use this phrase and grew up in Luton I forgive you; otherwise there’s just no excuse. This is the phrase which sparked this little rant so I thought it worth including.

Most people are capable of glossing over things like this, but unfortunately there are a few of us who are allergic to them. It causes this glitch in our brains which makes us scream and bang our heads on the table; the only cure is to discuss the problem at length with everyone else in the office. Please help prevent this utter waste of time and resources by remembering these few simple rules (particularly rule 1).

apostrophe’s
are rarely loved
they grow on tree’s
when their not shoved
out of the word’s
wots their’s by right
its not a very
pretty sight
it isnt all
they’re fault, you know,
they aint got nowhere
else to go.

—

If this resembles your lovingly crafted documentation / guide to your hobby / tutorial / code comment, you may want to enlist the help of a proof-reader. Here’s a quick guide:

1. its – like his or hers, which also have no apostrophes, means “belonging to it”.
2. it’s – like I’m, you’re, he’s, she’s, we’re and they’re, which have apostrophes for the missing letters, means “it is”.
3. apostrophe’s – means “belonging to the apostrophe”. This kind of abuse is known as “the greengrocer’s apostrophe”, as some greengrocers suffer from the mistaken belief that a carrot is capable of owning 20p.
4. would of – I think you want to use “would have”, or at worst “would’ve”. If you use this phrase and grew up in Luton I forgive you; otherwise there’s just no excuse. This is the phrase which sparked this little rant so I thought it worth including.

Most people are capable of glossing over things like this, but unfortunately there are a few of us who are allergic to them. It causes this glitch in our brains which makes us scream and bang our heads on the table; the only cure is to discuss the problem at length with everyone else in the office. Please help prevent this utter waste of time and resources by remembering these few simple rules (particularly rule 1).