Have you ever sat in a meeting where people seem to be arguing different points, and you suddenly realise that everyone is actually in agreement but they're just using different language?
The same kind of misunderstandings can happen with projects. This can lead to poor judgements, extra work, and cost and time overruns.
In my "War on Bugs" blog post, I described how Behaviour Driven Development (BDD) helps minimise the risk of these problems by ensuring that everyone involved in a project communicates with a shared vocabulary.
Dan North, a proud proponent of BDD, sums this up well: “Behaviour-Driven Development is about implementing an application by describing it from the point of view of its stakeholders".
The shared vocabulary then, shouldn’t mean non-technical people learning to speak in C# (or any other programming language for that matter) but getting the development team thinking in terms of the business users or clients and, as Dan North recommends, even using that language in the code.
This concept is closely related to an approach that software designer Eric Evans has termed Domain-Driven Design (DDD), which emphasises ‘ubiquitous language’.
Using this approach, we would expect that the foundation of the project, including the names for classes and data entities, will be formed around its stated purpose or goals. This will assist in any project discussions as the domain-specific knowledge of the business maps directly to the code and everyone is using the same terms to describe them.
In reducing project misunderstandings, businesses benefit from a lower risk of project overruns, and developers will need fewer iterations to get the job done right. And that’s good news in anyone’s language.