This post is inspired by a Tweet of mine on the subject of Behaviour-Driven Development. As my tweets are set to auto-delete after 30 days (as a matter of digital hygeine), I shall reproduce it below:

In the same way that a new requirement drives a new test, perhaps the use of the word "just" is a good indicator for an exercise in BDD

As a big fan and proponent of Behaviour-Driven Development, or Specification by Example, I'm always on the lookout for ways to better understand and model the "business domain", using business language. In the developer community we like to utilise the three-act play structure (Given/When/Then) as a way of semantically expressing these business rules. The exact format matters less to me than the conversations that happen in order to produce these outputs. What also matters are the examples that we use to decorate business rules, adding context and specificity.

One of my 'trigger' words is the word 'just'. It glosses over complexity. As someone who likes to get into the weeds of problems, that frustrates me. Very often the 80/20 rule often applies, where 'just' is mapping the simple business-as-usual processes, rather than the exceptional and more-complicated behaviours. But as developers building systems to model business processes, we need to think about what lurks in the weeds of the 20%. We'll probably spend 80% of our time there.

Some colleagues in the past have tried to ban the word 'just' for this reason, but I've found that synonyms will crop up instead, such as 'simply'. So instead, these days I use the word as an opportunity to begin an exercise of BDD. Let's put some examples down on the board to demonstrate how this works. The business representative is a subject matter expert after all, let them tell the story. Get them involved! Software development is a complex, multi-disciplinary endeavour. We require shared understanding to ensure we're building the right thing, in the right way.

So, don't ban the word 'just', use it as a jumping off point to have more conversations and gain a deeper understanding. The vast majority of the issues we run into during software development aren't technical, they're about communication.