When I first met Andreas Schliep, he told me a consulting war story with the punch line, “Well, you can paint that wall with a screwdriver if you like”¦” There’s no stopping people who are intent to use the wrong tool for a job, or use it in the wrong way. Sometimes it even works. I’ve seen someone successfully, after a fashion, driving wood screws with a hammer.

Now, Karlo Smid complains that Gherkin (given-when-then) is unsuitable for writing Shakespeare’s Hamlet. There’s not much surprise to me in that complaint. I would never attempt to write a five act play in Gherkin. Nor would I try to describe the desired behavior of a system in Elizabethan iambic pentameter.

Gherkin is useful for documenting expected behavior in language close enough to “plain English” (or other language) that non-technical people can agree or disagree that it represents what they want. It’s also precise enough that we can use it to check that the software does what is wanted, at least as far as specified.

Note that people study Shakespeare’s plays in great detail for years to glean the meaning of them. Newcomers to the study of Shakespeare, e.g., high-school students required to read Hamlet, for example, turn to explanatory works, such as CliffsNotes to help them understand the very basics, such as the timeline of what happens. This level of difficulty and ambiguity is not what we want in a document that describes the desired behavior of a software system.

Neither Gherkin nor Elizabethan English is likely a good choice for general discussion about what is desired in a system to be build. When the Three Amigos meet, they should talk in the language they normally use, preferably based on the language the business uses. Because the technical and non-technical people have different, if overlapping languages, there will be some need to check the translation. One way to do this is to offer examples of what is understood. These examples provide a concrete description to accompany the abstract “requirements” and help ensure we have shared understanding. Otherwise it’s far too easy to agree on the words, but not the meaning. The examples test the “shared-ness” of our understanding.

The examples also provide a good basis for later checking that the resulting software behaves according to that shared understanding. That’s why we then translate them into Gherkin, and verify with the business that the Gherkin still says what they mean.

Sadly, in Karlo’s list of “the best sources of communication,” talking with the business people who know what they want the system to do is not mentioned. I wonder how he knows whether or not it meets their desires.