Behavioural Development

There seem to be a lot of seemingly-unrelated buzzword-oriented software development methodologies being flung about these days. Many of them have been around for a while, & I suspect that they've been so under the radar that anyone with experience expects them to be known, but someone who hasn't been keeping up will think of the concept as "new & exciting".

That's how buzzwords come about, in general. The people who use a concept when it is new come to a consensus on how to short-hand a long & complicated term that describes what they're doing, & then those not involved pick up the short-hand to use it as if they know what they're talking about, making it into a meaningless buzzword.

As an aside, I remember drawing a lot of networking pictures where we represented the internet as a cloud of unknown & unknowable infrastructure that "our servers" hung off. The cloud hasn't moved, only our perceptions have.

People are talking about BDD as a necessary skill for developers. Most people don't have a good understanding of what that really means.

Historically, BDD comes from 2006 when Dan North decided that TDD wasn't enough in itself. He started writing acceptance tests in the same style as user stories (Connextra, 2001). His implementation of JBehave, which developed into RSpec & then Cucumber over time (with David Chelimsky & Aslak Hellesøy), meant that specifications in user/system behaviour could be implemented & then become acceptance testing.

TDD had been around since 1999, with the test-first principle of the XP methodology. However, tests were usually based on use cases (Ivar Jacobson, 1986) - easier for devs to understand - rather than user stories (coming from BAs), which is where North's disconnect was. To this day, TDD tends to stay within dev-space, while BDD can extend across product development. The unit testing tool xUnit (JUnit, HttpUnit, etc) was Kent Beck's brainchild first for SmallTalk (1998), then Java (with Erich Gamma), thus causing the development of mocking (2003), dependency injection (2004 - Martin Fowler), etc, all to support both testability & acceptability of software solutions.

Enough history - all I really wanted to say is that BDD has been around for a long time, & it's only now catching on with the late adopters.

Now for the important bit - it doesn't matter what technology you use, what language you implement in, platform you develop for, methodology you espouse, or even effort you put into adopting industry best-practices. What really matters is the team's attitude towards the work itself.

BDD only works when you have an agile team which incorporates stakeholders in the daily stand-ups. It only works when the user stories are written up front in a non-technical manner by a domain expert (who is, or represents, the product owner). It only works when the behaviour of the team has been developed to the point where better product is the driver for adding features & proving their effectiveness.

The behaviour that should be developed is that given by Aslak Hellesøy - "[for a given feature] pop the why stack ... until you end up with one of the following business values:

• Protect revenue
• Increase revenue
• Manage cost"

Encourage an environment that allows every stakeholder in the product development process to ask that question (repeatedly).

Language Functionality

I like to think of myself as adaptable. Having said that, I've been living in the Java stack for quite some time & am perhaps too comfortable in a strictly OO world.

To prove adaptability in the extreme, I've taken to a functional bent with my programming. If you don't know why anyone would deviate to functional, some light reading might help:

• http://www.techrepublic.com/blog/software-engineer/when-to-use-functional-programming-languages-and-techniques/   

• http://www.javaworld.com/article/2078610/java-concurrency/functional-programming--a-step-backward.html

I decided to implement a problem in several languages that I am only now learning to use in a serious sense, each with some level of functionalism (picked at random):

• Java 8 (beta)
• Java with Guava
• Scala
• Ruby
• Groovy
• Python

I don't want to get into the nitty-gritty of comparing the languages, as such, because that's not the point, except to say that Java is not functional, & therefore adding the Guava libraries to it doesn't make it so.

I started each dev task with a perusal of simple tutorials to orient myself in the language. In the case of Scala, that was already aimed at Java devs (thankfully), & in the case of Ruby & Groovy, I left off the Rails/Grails bits for later.

I kept thinking "Oh, this language's approach is like that language except for ..." & then it dawned on me that each of the languages actually had their own distinct (if only slightly different) approach to doing exactly the same thing.
It got to a point of being annoying. I could take the structure of a Scala class & turn it into a Ruby class, & there would be line equivalences in almost all cases - but each line would be different. The symbols for making lists or maps or key-value pairs would have to change, the names of simple methods would change (key?, containsKey, etc), to the point where a cursory examination would elicit the question "How are these languages different?", yet a thorough examination would rather ask "WHY are these languages different??"

My answer? I don't know. I honestly don't. It's easy enough for a proficient professional to learn one of these languages quite quickly given another, but what do they gain in doing so? Most of the list have been ported to the major operating systems (with varying degrees of usefulness).
I even managed to get some joy out of developing my solutions from within the one IDE (eclipse with a lot of plugins, coercion & stress - & some loss of functionality).

But then, haven't we already gone through this - if you take C++ & Java, you can look at the implementation of methods & see strong correlations (fundamentally procedural), but the structure of a solution will likely vary because of specific things you can & can't do in their object-orientedness - inheritance being a classic difference.

My point? We keep trying to reinvent the wheel by using different materials to create smoothness or hardness or roundness, but it's still a wheel, & it's well past time we got on with inventing hover boots.