The Fundamental Problem of Software: Translating Business Rules into Code

How Behavior-Driven Development (BDD) can help solve the fundamental problem of software. 

Translating language – an example

In true BDD fashion, let’s start with an example: Carlos is fluent in Spanish, but does not speak English. Mary is an English speaker who knows little to no Spanish. However, Carlos and Mary wish to communicate. What’s the first problem in communicating? Well, obviously they don’t understand each other. So the first problem is we need someone who understands the original language. Enter our translator, Barbara, who is fluent in both.

What’s the next step? Carlos says something to Barbara. We’ve established that Barbara speaks both languages, so she understands what Carlos has said. So the next step is she needs to convert from the original language to the target language. She tells Mary in English what Carlos has said.

The final problem is we need to verify Barbara has said the right thing. Our whole exercise is futile unless the translation is accurate.

The three problems

So we can see that there are three problems in our example and they map exactly to the problem of software:

• Understand: We need to be clear on what we are trying to accomplish in our software, or we have no hope of building the right thing.
• Translate/Convert: We need to write code (software) that accurately translates the business rules into something computers can work with.
• Verify: We need to be sure that what we’ve coded truly does solve our original problem.

Understand

Behavior Driven Development first starts by using examples in conversation. This is the most crucial step in the entire process. Generally, this is done through a meeting of the Three Amigos – a Business Analyst, a Developer and a Tester. By using concrete examples of what the software should do, we are making sure that everyone on the team understands the business rules. These conversations are not only helpful for developers and testers; they often help uncover scenarios the business may not have thought of or didn’t state clearly. By facilitating the conversation amongst all team members, BDD helps us nail down our understanding and formalize it into scenarios.

Translate

As we set out to design our system, we’ve been given all of the information necessary to form our architecture. We can clearly see what objects we need to create, what actions we should give them, and what properties each of them has. By working through each example, our system steadily builds itself into a proper model.

If we don’t see something clearly in our examples, we can defer building that piece until a new example requires it. This is a very helpful aspect of BDD as many engineers (myself included) are tempted to build out more than is necessary on the assumption it will be needed.

This isn’t a magic talisman that prevents bad code nor will it turn mediocre engineers into wizards. But by providing a clear path to victory and a list of steps along the way, it vastly lowers the difficulty in building each piece.

Verify

By using our examples created in the understanding phase as automated test scripts, we now have an excellent way to verify the output of our translation. If something fails, we have a clear point of reference in the system to look for bugs. The examples that drove our design are now providing the constant smoke test that we got it right. This gives us the confidence to know when we are ready to ship or to refactor and tweak as necessary.

BDD provides the perfect environmental mix of discipline, structure, and automation to nurture the growth of great software. It addresses the key need of all projects to accurately move business rules into functional, reliable code.