A short film about bugs...

...which starts with an apology for the pretentious title.

1. Anyone can identify a bug.
2. Many fewer people can resolve a bug.
3. Far fewer still can anticipate a bug and stop it from rearing its ugly head.
4. Anticipation is a greatly under-estimated skill.

Software Reliability and Volatility

I've been working a reasonable amount of late in dealing with considerations of software defect management and metrics to indicate "software reliability". Personally, I always think that reliability is a continuum (like trust), and that a software is only as reliable as its last failure. Software which predictably fails big and often is obviously "unreliable", but much software runs fine most of the time until something "unexpected" happens...is this software then unreliable? Well probably not until it starts failing more frequently, and more predictably, and therein lies the problem: it is difficult to know how reliable a software system is until it stops to be reliable.

There are pretty much two approaches to reliability - one is based upon trending, and the other on prediction: while I much prefer the trending approach which says check how reliable your software could be considered now, then check at now+1, take a look at the rate of change and this is the indicator as to your vector of reliability, I also think that taking a look forward with a decent prediction model, can help to set a sense of expectation.

I think this sense of expectation is best summed up in the idea of "code smell" or "defect risk", which could be considered as "is your code smelling better or worse over time" (trend) and "is your code likely to smell worse at any point in the future" (prediction). There are obviously complexity, coverage, sizing, and defect tracking rules which can be applied, but I really like the concept and approach to "volatility" as set out in the article: "Software Volatility" by by Tim Ottinger and Jeff Langr in the latest Pragmatic Programmer Magazine, since this seems to blend trend and prediction together: the code which you touch most often is the place where code is most likely to break, and the more you touch it, the more likely this is to happen.

I strongly suggest reading the article, and look to applying a similar approach in a balanced reliability metrics scorecard and inspection process. I certainly don't think that it should replace coverage (which lets you know where you have unit tested), cyclomatic complexity (which lets you know how many tests you should write, and when you might want to consider refactoring), sizing (which just gives you a volume idea of what you are looking at), code analysis (sort of spellchecking for your code), defect classification and tracking (for failure rates and densities)... but it certainly represents a tool worth sharpening and adding to the toolbox.

Use Casing with Your Clients - BDD or Given, When, Then...

Sitting at home, feeling sorry for myself as I am off work sick, I thought I might write a short blog post on using Behavioural Driven Development (BDD) for Requirements work with clients - a technique which I am starting to use with some (note the qualification) success.

I'm a big fan of use casing "As is" models and "To be" models to get a really nice sense of the contexts in which a system is supposed to work (and by system, I mean people, process and technologies), but this can be hugely tough unless you are working with clients who are formal, systematic, logic-driven thinkers.

And this is how I stumbled upon Dan North's BDD - as a way of reducing the formal use case methodologies (pre- and post-conditions et al.) into a very simple story formulation.
Feature: As a stakeholder, I need a something, in order to meet my goal (High level business requirement - main system "features")
Scenario: Given a starting context, when something happens to change this context, then this should be the result. (Lower-level scenario and low-level "feature" descriptions).
Note: I write "feature" as feature is a controlled word in BDD.

The greater joy of this technique is that it effectively shrinks the distance between what the client says he wants, and what your technical team is capable of delivering back to satisfy these requirements. Why? Well, as this fine blog post points out, it is because this is a business language way of describing states, event triggers and test conditions. Even more importantly, through the use of JBehave or Cucumber with Automated Testing tools like Selenium, your developers can start by writing failing tests for your requirements (requirements-driven, test-driven development), and then - if it is worth the overhead - write automated functional and acceptance tests.

I'm desperate to get this rolling from Business Contact through Business Analyst to Developers and Testers within the company I work at - but I wondered if anyone else has gone ahead and implemented this fully as an end-to-end requirements and development methodology. In the meantime, I'll get my act together and make a couple of posts (when I'm feeling better) as to a few workshop techniques which work nicely for the client-end of BDD.