Archive for March, 2012

The application I am currently working on is going through dramatic changes, which reflect the change in the organisation as a whole. Nothing new about that of course. It is interesting, and a credit to the people that built the application originally, that much of the change required can be achieved through configuration and modification to reference data. Quite alot can even be done by the business users themselves. That’s not to say it has been easy to define what we need to do though, as it absolutely hasn’t been.

But my question quite simply is this: Should one attempt to employ BDD in this sort of situation? I have attempted to, but quite frankly, it is hard and unwieldy. I am not convinced it is even assisting us. What is required is some means of describing what is currently there and explaining simply and easily what changes we need to make.

This could be done as a simple check-list – which perhaps is all that is needed?

I am not an SAP person, but to widen the question, can you use BDD successfully on a SAP system, given that SAP is probably the archetypal case of achieving changes through configuration rather than development as such (I suppose a more dramatic example of my situation). The paradigm with SAP tends to be about the organisation adapting to the software, rather than forward-engineering “features” which is what BDD it seems to me, is geared towards. So should one attempt BDD here? I suppose I ought to just go downstairs and just ask the SAP team.

A colleague of mine is involved in a project to modify an existing application that our team are responsible for. For those of you that follow this Blog, the scenario is a familiar one: The application isn’t very well understood, yet it is live and in use. Meanwhile the team that built it have long since moved on and the business area in question has restructured with many people leaving and joining. Oh, and there are the inevitable challenges of budget and timescales.

One of the biggest challenges has been – apparently – getting the developers engaged, given that at the beginning there was a fairly sketchy set of requirements and obviously a sketchy level of understanding about the ‘as is’ situation. So the first step was, quite rightly, to assemble a level of understanding of what is currently there. This of course, requires developer involvement.

“How do you expect us to produce engineering estimates for this?” Came the cry.

And therein lies the problem. Development isn’t always about forward-engineering a solution. It isn’t just about building new features. It’s great if it is, but sometimes development is about untangling what we already have, or reverse-engineering what others have left us. Thats the reality. It might not be glamorous work and might not get you up on stage at an Agile conference, but thats’s life. These activities inform and shape what comes later.

In the meantime we could, I suppose, write a story like “as a user I want the system to work so that I can do stuff” but what’s the point? it doesn’t get us anywhere?

I’ve always taken the view that ‘Analysis in progress’ doesn’t just mean Business Analysis. Analysis can take many forms – It can equally mean technical analysis, or more accurately, a developer prowling round the code to find out what it is doing. The idea that you can start with an “engineering estimate” or even that you can start with “stories”, is nonsensical if this bedrock of knowledge, understanding and investigation isnt there.

My ‘Grand Designs‘ analogy is that if you watch the programme you’ll notice that the problematic building projects tend to be those where they are altering or renovating something that already exists because they are never too sure what they will uncover. Uncovering the unexpected and having the project go awry as a result doesn’t represent some massive conspiracy or wrongdoing, just life. Building something brand new on a plot of land is, on the other hand, oftern far easier and sometimes quicker. Furthermore, it is much simpler to describe how you want your brand-new purpose-built-from-scratch home to look, than to describe how your house conversion/renovation will look, since there might be many constraints and oddities around a conversion that can’t be altered. Not all of these will be known at the start so things may change after you’re underway.

IT is no different. Dealing with something that already exists, is often (if not usually) far more difficult to deal with than a brand-new development. It probably shouldn’t be, but there we are. Also, Agile is at it’s strongest when dealing with the ‘new’.

So, at the risk of repeating myself, the fact is that “Stories” and “Engineering estimates” and all the rest are often the product of the analysis. Not the input to it. Not everything is a new, “green field” development. We are often faced with “brown field” developments – which I suppose are good for the environment if nothing else….

Once upon a time there was a service called Prestel The idea was that by connecting a computer to the telephone line, you could access a remote central computer containing a database of information. A kind of much expanded and turbo-charged Teletext service. Further, and unlike Teletext, you could interact: You could send messages to other users, order goods and services, make reservations, and take part in various multi-user facilities such as chat rooms.

Sounds a bit like something we have today?


Nowadays, Prestel has long since disappeared and is virtually forgotten. IT, never an industry to have much regard for it’s own history and heritage, doesn’t celebrate past advances much. Even important historical figures such as Alan Turing (who is becoming regarded as something of a father of computing) are almost unknown today. It is left to volunteers and enthusiasts to raise the profile of the past. (A tip of the hat to Jason Gorman and others who are doing this).

In one of my less successful predictions (though to be fair, I was still at school when I made it), I thought at the time that Prestel was the future. I thought people would embrace it with open arms. Instead it was pretty much written off as expensive and pointless by most and never achieved more than 90000 subscribers. In a weird twist of fate, the point at which It may have started really breaking through into the mainstream coincided with the internet and World Wide Web taking off. It is perhaps Ironic that one of the reasons for Prestel’s unpopularity was the fact that to connect to it involved the cost of a local telephone call. Yet when the web took off (in the era of dial-up modems – no broadband yet) people seemed to forget that that was exactly what they had to do.

The rest is history. Prestel was dead and buried before it even got properly started.

Should we feel nostalgic or emotional about such things? I do – though I’m not entirely sure why. In a way, you could just dismiss the whole thing as a failure. After all, many printed magazines had more subscribers than Prestel ever did. But it did do one important thing: By planting the seeds of an online world, people could at least see the possibilities for real. It wasn’t just research lab theory – It worked. Technology could deliver instant information and interaction into your home. People hopefully would (and did) get enthused and strive for a bigger, better and more ubiquitous online world. And we all know where that led.

Am I alone in thinking the new iPad 3 is a massive disappointment? It got plenty of media coverage, but I have to say, walking past the Apple Store in Covent Garden at the weekend didn’t show much evidence of frantic queues to buy them.