Ethical Software by Alex Bunardzic

We’ve seen how Contract-Driven Development failed to improve the quality of delivered products. The reason for that is simple — if a developer is not fully competent to deliver high quality code in the first place, chances are nil that the same developer would all of a sudden and magically be capable of formulating high quality contracts. And if the contracts are crappy, the resulting code is going to be crappy as well (the time-honored ‘garbage in, garbage out’).

Because of that, Contract-Driven has been changed to Test-Driven Development. Alas, the results were similar. Dave Astels, one of the most prominent figures in the TDD world, laments: “Too few people I talk to really understand what it’s really about. That means that many people who practice TDD are not getting the full benefit from it.” (A New Look at Test-Driven Development)

To remedy the situation, many TDD advocates propose that we change the language describing this new approach. Instead of ‘test’ they suggest we use the word ‘behavior’. So now it’s Behavior-Driven Development (BDD).

The Way the System Should Behave

But Behavior-Driven is too vague. Every system behaves, so relying on the system behavior to guide the development is a bit dicey. It’s quite easy to slip into detrimental behavior, an then be led by it to a disastrous end.

What they really want to say is that the method needs to be called Should-Driven Behavior. Only focus on the way the system should behave. The system could behave in many different ways, but there is usually only one behavior that is desirable from the user point of view. And that behavior is the way the system should behave.

However, the problem remains. Even if we focus solely on the way the system should behave, it does not guarantee that we’ll deliver high quality code. It would be very easy to ‘bark up the wrong tree’, and chase after some phantom desirable behavior that is in reality way off mark.

The essential problem remains — how to figure out what is the desirable (as opposed to the merely desired) behavior of the system? How to know how should the system behave?

And for that, no amount of clever gimmickry and prescribed methodologies is going to help us. Only plenty of experience and plenty of common-sense can lead us out of that conundrum. Even working with customers and end users in an agile, tightly coupled loop is not going to help. Even customers and end users typically do not really know what is the truly desirable behavior of the system.

So again, it all points back to the human factor — the challenge is to find high quality experts. Once we assemble high quality team, the methodologies they may or may not employ are pretty much irrelevant.