Six ugly words

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:

Right Wrong
Should Ought
Control Hold

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?

This entry was posted in Uncategorized. Bookmark the permalink.

9 Responses to Six ugly words

  1. anonymous says:

    I think it’s a good suggestion.

    Clearly states the expectation, not a presumption.

    – Jake

  2. anonymous says:

    I suggested it to Dan some time ago, but he didn’t like it. Perhaps you will have more luck than I did.

    Another reason to prefer “will” is that JBehave treats tests as specifications (or vice versa). However, the word “should” has a very precise meaning in a specification; it means that the implementor should support the specified behaviour but that clients of the behaviour must cope with the specified behaviour not being implemented. This is very different from what JBehave means by “should”.

  3. anonymous says:

    I still haven’t got on the JBehave bandwagon though I find the approach interesting. I think I do prefer the “asking the question” feel of “should” over the “commandment” feel of “will”.

  4. anonymous says:

    Now you just need to convince Dan!

  5. anonymous says:

    I like to drop the helping word altogether and write specifications in present tense:

    ShapeBehaviour.rotatesRightSuccessfullyWhenNotBlocked()

    As for “should,” I don’t like the word for two reasons. First, it’s ambiguous. “You should X” might might mean “I want you to X.” It might mean “I expect you to X.” It might mean “X is a good way to achieve <some goal that you’re trying to achieve>.”

    Second, and probably more importantly, “you should” sounds like a statement about you, when it’s really (in most cases) a statement about me and my desires and expectations. The wording “you should” deflects responsibility from me to you, which is a slippery thing to do when I’m really talking about what I want or expect.

    So I prefer replacing “should” with whatever I really mean: I want you to X, I expect you to X, or X will help you to Z.

    Dale Emery
    http://www.dhemery.com

  6. sirenian says:

    It’s less ambiguous when it’s, say, Shape.shouldXXX (ShapeBehaviour contains the behaviour of all Shapes). I like rotatesRightSuccessfullyWhenNotBlocked, but it’s useful to be able to easily identify behavioural methods, and the use of will or should encourages the use of the given – ie: the WhenNotBlocked.

  7. sirenian says:

    “Shall” is cool. I like “Shall”. A very underused word.

  8. anonymous says:

    further, will and should:
    help you to write a meaningful sentence about what the class should/will do
    help you to think about what the next most important thing the class should/will do
    help to gain consistency, at least in naming, across all of your behaviours.

  9. anonymous says:

    I think that ‘Should’ and ‘Ought’ induce stress when they form part of a context that we do not accept, or if no context is specified, for instance:

    – You should write functional tests

    Here’s a fully qualified version:

    – If you want to prevent regression bugs cheaply then you should write functional tests.

    Common (but incorrect) wisdom says you can’t get an ought from an is. Well when you supply a context you can.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s