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.

The Workspace Race

If you had asked me without pre-amble what I thought about open-plan offices, I would probably have answered that I had almost always worked in them. Within IT, it's very much the norm. In other office environments, it became a fashion for various reasons.

It makes sense in IT where there is a collegiate atmosphere - people collaborating on a project or related technologies, constantly in need of a few minutes interaction to verify an idea, even if they're not pairing up on the same task. There is no privacy, but the theory goes that you shouldn't need any. Open offices are great space savers, too, because you can pack more desks in.

The next step up is the good old cubicle, which gives you a sense of being cut off from the rest of the team - usually with your back turned to the place where people come along to bother you. Depending on whether it's a half-height (easily lean your elbow on the top to talk), of full (can only stick your head over the top), the cubicle walls are a barrier of mixed blessings. This is fine if you're not collaborating much, or if there are a lot of break-out spaces.

Then there's the office - a place where you can shut the door if necessary & block out everything but the fact that people keep walking past in the corridor. You can ignore knocks on the door, if you're lucky, or invite people in for an intimate chat. In IT, this is usually a great luxury.

The open plan works for IT, & it has a great history of working for different occupations down the centuries. We can easily imagine a Dickensian scene of accounting clerks tallying their numbers to a slight murmur of pages swishing & pens scratching, usually placed around the pedestal of the supervisor. We can also imagine a middle-ages scriptorium filled with monks carefully copying manuscripts with their coloured inks in precision, & the librarian available for consultation. Open plan.

I'm not suggesting that IT people are necessarily celibate or in need of constant supervision, but the idea of a space being open & littered with desks so that people share the experience while doing work that requires great concentration has a very long tradition.

I'll just throw in a bad example or two - imagine a 1950s secretarial pool with a sea of women typing up from short-hand notes at tiny desks, & the constant clatter of typewriters. Not my scene. Finally, a chicken farm, with rows on rows of confined birds doing the only task they know how (& have room for) - laying.

The modern equivalent offices are customer support & telephone sales people.

Understanding ergonomics & OH&S will not change the applicability of an office plan to its usage. There is never a "right" answer, there is just effective use of the space available. If you don't put that thought in, & review the results, & ensure that the reviews are meaningful, & act on what you've learnt, then there is always an impact. That impact is a decrease in productivity & increase in staff turn-over, usually - direct costs to the business.

Using the space for the purpose at hand is like choosing a methodology for product development. Throwing some furniture together & spreading resources about will never be enough to make a project successful. Open plan encourages open communication, but doesn't cause it. It is also true, though, that closed doors ensure that there is no communication.

The Full Story

A friend recently pointed out an article that said that presentations are slowly pulling away from buzzwords & bullet points to be more engaging by telling the full story. This means that the audience is using a much more receptive part of their brain.
I was reminded of an old cartoon (strangely, I don't think it was Dilbert) where someone plays buzzword bingo during a presentation. That's about as exciting as it gets sometimes when someone presenting is simply throwing their viewpoint at the audience to either justify their existence, or else prove how clever they are. I'm not saying that consultants are the main culprits...

This is in line with how software development has been moving from requirements that read like bullet points ("name entry field must be twenty characters") to use cases ("the user enters their name; the entry screen validates the length; the database stores it in a field") to user stories ("as a user, I want to provide my full name, so that it is stored in the system"). Well written requirements are cutting out the "translation" steps from analysis to functional specs to design, etc, causing the developers to understand how the system really works with respect to the user, & ensuring that developers & testers are working to the same end goal throughout - they're using more of their brain.

Going back to presentations as a story - if you have a mixed audience, you tend to either dumb down the bullet points to the lowest level, or else ignore that sector & pitch directly at the money men. Telling a complete story (the old-fashioned way) means weaving into context the ideas that you want to get across, & also taking non-verbal feedback from your audience (fidgeting, worried expressions) to change gears & ensure that your ideas sink in.
It used to be accepted that only ten percent of a presentation (or a university lecture) is actually remembered. Why is this acceptable? Why waste your time giving the whole presentation when you could stop at the first yawn? If you engage your audience more, then maybe twenty percent will sink in - doubling your chance of a sale/investment/interest/support.

The same goes for software development. A two-hundred page spec written by a BA that gets translated into twenty different people's implementation of functions & tests is guaranteed to fail, because there is no consistency of interpretation. You cannot make a bullet-point spec so interesting that people will want to go back & re-read the fine detail, so they'll read once, hope that they have it clear in their head, & never go back to it - ninety percent loss of information.
A user story, however, relates to one piece of behaviour in a given context, clearly stated. Once that behaviour is correct, there is no going back to re-read, there is only (automated) regression testing.

User stories & TDD (test-driven development) or else BDD (behaviour-driven dev) speak directly to the BA's audience. Of course, the best way to do this is within an environment that fosters co-operation, so I do mean an agile methodology.

Hereafter, the person telling the story is not an external consultant proving how clever they are, but a part of the team who all want to know what the full story is.

Curves Ahead

When you're driving at speed & you see a sign that says something like "Curves Ahead", it's a good time to slow down.

When you're on the bleeding edge of technology & you're ahead of the curve, the trick is to maintain speed, hang on tight, & ride it out.

In a way, the same thing is generally at stake - your future. Drive too fast & you won't have one. Make a wrong technology choice & you won't have one. The difference is that very few people drive in a competitive market.

Getting ahead of the adoption curve is very risky, & it doesn't always pay off. There are often choices that get made way back in the journey that don't let you change the technology route. If you're developing for the iPhone/iPad platform, the question is not if you'll support the recent iOS release, but how soon you can - how fast you'll take the curve - because the customer base is ahead of you.

But there are some choices that can wait - like supporting new standards before they're implemented. It's great to have a tinker with Java8, but try to incorporate it into your IDE, let alone hoping it will work reliably in beta. What about HTML5 & CSS3. Everyone seems to want to develop ahead of the curve, but in this case the customer base isn't really there yet because browsers aren't fully compliant & users are notoriously bad at upgrading their browser anyway.

Being in a beta program is a great way to look around the curve & influence the landscape ahead, but you don't want to drive around a blind corner to discover that the road hasn't been built yet. I remember Bullant Technology, & how it was going to revolutionise the web with high-speed transactions. Whole companies drove off that cliff.

Professional drivers use their experience & develop techniques to stay on track & stay alive. Professional technologists rely more on luck & gut instinct to live by the choices they make. If they fail, they move on to another race. Can we measure the success of a technology driver? Can we see how the championship points table stands?
At least that sounds easier than looking at the manufacturers' points table - they tinker with the technology vehicle so often it's hard to tell what's being driven at the front of the race.

Abusive Language

Sorry to disappoint, but this is actually about Java8.

A long time ago, I was an academic, & we used to teach object-oriented programming in C++. How naive! This was when Java was a mere pup, so it wasn't really an option. The important thing was teaching object-oriented-ness (in theory) & then showing the students how to use it in practice.

Years later, I went from being a C++ developer to being a Java developer - during the war. No, I don't mean a military conflict, but the point when those two languages had some commercial altercations. Propaganda leaflets were dropped from skyscrapers with strident calls for "Multiple inheritance!", etc. There was a lot of discussion over maintainability, libraries, the friendliness of the language (readability), the viciousness (the ability to write bad code), etc. In the end, Java "won out" because it was more web-oriented, & then a lot of the C++ world turned to C#.

A few years ago, I was introduced to Scala. Without delving into it commercially, I could see that it had become an academic favourite because it was a way to do functional programming - which represents theoretical ideals - & it also runs on the JVM, which makes it Java friendly & more useful than Haskell. At the time, I thought "nice theory". I couldn't see how functional was going to take the commercial programming world by storm, or how a new language would fit in. Who wants it?

Now I've got my dev copy of Java 8. Each of the previous major upgrades has been an improvement - some in efficiency of the JVM, some in better coding style. Up until now, though, the introduction of generics, which was effectively C++ templates a long time overdue - was the biggest change to the way Java is used. Some would say that annotations were as big a change, but this depends on whether you take advantage of frameworks (Spring, Junit, ...).
Java 8 has Lambdas.

Although you might think that anonymous classes & defining callback interfaces had already covered this area, it was messy, so you avoided it. Now, there is encouragement to be functional. It will be easier to write functional code within object-oriented Java. You will discover that you'd been doing it quite a bit before (in event handlers) & can do it better & more often.

Here's the kicker, along with the new way of writing lambdas (which is VERY concise) come other short-cuts influenced by Scala & Ruby that do seem to take away some of the elegance of Java - where verbosity was often a blessing. I can recall, during the war, how we were told to avoid inline-conditionals, on the basis that they made code unreadable. Now we have inline functions.

Is there a driver for making things easier or quicker to type? I thought that's why we used IDEs with short-cuts. Good code design & development can be partially auto-generated from UML (theoretically), then the features defined in TDD before the implementation is begun. XP's mantra of pair programming is distinctly on the side of "think before you type".

There has to be some balance between introducing new language features that work elsewhere (lambdas, generics, annotations) & staying true to how that language is used professionally (readability, testability, design).

In the world of written & spoken languages, some countries have committees that ensure the "purity" of the culture represented by the language. In Java, we have Oracle & OpenJDK. At some point, you have to ask whether new concepts need to be incorporated into the culture, or whether they would just be an abuse of the language.

Tell 'Em

In one of my early consulting roles, transitioning from a technical consultant to a management consultant, I received some great advice from someone who had been in a purely consulting role for most of his career. Ironically, he'd been a student of mine when I was teaching the technical side.

When making a presentation, you can't make assumptions about your audience, & they won't make assumptions about you, so the best way to communicate your message is in three steps:

1. Tell 'em what you're about to tell 'em.
2. Tell 'em.
3. Tell 'em what you told 'em.

I know that sounds stupid, but it's true - have an introduction that explains what the presentation is about, then have the presentation, then a summary that reinforces the key messages.

When put like that, it's obvious. But how often do you present like that? Or how often do you sit through a presentation that has a middle & no beginning or end, where you walk away wondering if you missed something?

What has all of this to do with software development? Seriously - shouldn't this be in yet another blog? Well, no - software development has an equivalent.

1. Tell 'em what you're going to build.
2. Build it.
3. Tell 'em what you built.

Again, bleedingly obvious. Again, how many times have you not done it, or seen someone else not follow the pattern?

How many times has what has been delivered been a complete surprise to everyone? Or been ignored or misunderstood? What about the broken promises?

All sorts of software development infrastructure go into the three-step process - budget allocation, project sign-off, executive buy-in, business analysis, product management, user acceptance, test planning, marketing. All of the machinery around developing software relies on the three steps being there.

It is imperative that

1. Communication occurs before a software project starts, ensuring that the project parameters are understood & accepted, producing a plan.
2. The plan is followed, & variations are communicated (where agility allows for variations).
3. Deviations from the plan are communicated (plan hasn't changed, but the project has), & it can be shown how close the delivered product is to the intended one.

It isn't rocket surgery, but it is sound advice - even if I received it from a consultant.