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?
I think it’s a good suggestion.
Clearly states the expectation, not a presumption.
– Jake
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”.
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”.
Now you just need to convince Dan!
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
It’s less ambiguous when it’s, say,
Shape.shouldXXX(ShapeBehaviour contains the behaviour of all Shapes). I likerotatesRightSuccessfullyWhenNotBlocked, but it’s useful to be able to easily identify behavioural methods, and the use ofwillorshouldencourages the use of the given – ie: theWhenNotBlocked.“Shall” is cool. I like “Shall”. A very underused word.
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.
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.