In the BDD paradigm why should the "ubiquitous language" be merely semi-formal and not completely formal?

Question

Here's the relevant quote:

A common risk with software development includes communication breakdowns between Developers and Business Stakeholders. BDD uses the specification of desired behavior as a ubiquitous language for the project team members. This is the reason that BDD insists on a semi-formal language for behavioral specification: some formality is a requirement for being a ubiquitous language. In addition, having such a ubiquitous language creates a domain model of specifications, so that specifications may be reasoned about formally.

I'm thinking an actual formal rigorous "language" that has a grammar and compiler could be useful for, say, auto-generating test stubs from specs or for guaranteeing that specs have certain properties (consistently named nouns and verbs, etc.).

In the BDD paradigm, then, why should the "ubiquitous language" be merely semi-formal and not completely formal/rigorous?

Answer 1

The "ubiquitous language" should be semi-formal because you want to have conversations about how the code should behave.

If you make the language formal, you'll end up having more conversations about adhering to the formal language than you will about the behaviour of the code.

I wrote a blog post that illustrates what happens when the concept of formal examples is taken a bit too far. The ability to simply have a conversation, be forgiving about the language used, and sort the rest out later, is key to successful BDD. Here's another blog post on deriving Gherkin from conversations which might also help.

Answer 2

go ahead an formalize the ubiquitous language if it helps describe/define/solve the problem in the chosen domain - that's called a Domain Specific Language

But don't expect business users to write DSL; it's enough if they can read it, to facilitate the conversation described by Lunivore