No Silver Bullet in Software

Today's post is not so technical but still talks about the software existential philosophy in an informal manner. I remember when I was an amateur, was fixated/obsessed on every cool software ideology. It’s like having a spanner/fix and trying to apply that on every single bolt/problem I came across. This is quite common in early stages of any profession, where the pursuer doesn't have a big picture about domain of interest, and hence doesn't have judgement or acumen to weigh pros and cons of an approach. On turning back, one realizes how naive we have been. Time has come now that, we see panoramic view of the software domain (relatively speaking), we laugh at ourselves and it’s quite a revelation too.

Now, how does above story fit into software story? One learns hard way that architectural / design principles and concepts are not silver bullet, in the sense that, they cannot be applied like the spanner on every bolt we come across. We need to consciously and meticulously weigh and factor the advantages and disadvantages in a disinterested/unbiased fashion. Like if you take, one shouldn't be fanatical on principle - "flexibility of code" and apply in every scenario, region, routine and sub routine of code. This on the other hand obfuscates things and becomes a maintenance nightmare. One should use his/her best judgment in applying these principles. This can arise only by experience and experiments.

Is BDD (Behavior Driven Development), a panacea for high quality software?

This post tackles relatively hot topic in software development and that is "Behaviour Driven Development"(BDD). It insists on defining the term BDD, talks about evolution of BDD, business justification of BDD and finally describes a fitting real world experience. I have made an attempt to cut to the chase and take a stab at the core. This post is for software managers, developers, architects and business analyst.

Background:

We are in a software era of asserting that; ever-increasing complex code base performs what it’s intended to perform even after making a minor to massive modification. This obsession with guaranteed assertion is what resulted in inventing automated unit test cases and consequently, we want an assurance from point of view of business stakeholder, that the software works as expected after critical integration or pre-production."Which means that, we are not satisfied with code level function testing, which by the way is misleading and non-exhaustive, but we want feature level function testing, giving solid assurance to the business team. "Behaviour" is a contextually loaded word introduced by Dan North in software development, which evokes a notion that we are developing software through the guidelines of how software should act towards the pre-set goal.

Is BDD the evolution of TDD? YES.

Paradigm:

BDD is quite a different paradigm. Different in the sense, that it’s not method/class level validation but at feature level. Also, BDD takes all the pieces and concepts from TDD expect that, looks through the lens of testable working high value features. TDD on the other hand allows one to develop unit test case that asserts the functionality of the given method or a given class. Which is good but hardly protects and convinces the business stake holder’s interest, security and a good night sleep! We need unit test cases woven together to demonstrate and validate a single scenario/feature like for e.g.: What happens in fulfilling the order process requirement?

Real world experience-

I remember working for a healthcare firm where in, the business stakeholder configured a set of input/output pair for a given piece of feature/function,  through a web GUI, and the developer's test case would pick the configured "input", and perform the corresponding weaving process, through collaboration of different objects and corresponding methods. Thus after executing and asserting (multiple) the behaviour, the output results are matched against the configured output pairs set by the business stakeholder. And subsequently this indicates a green signal at each stage of assertion.