Archive for August, 2012

Have a think, and i’ll meet you back here in a week or so’s time…

I had a manager once who said to the effect that IT was like walking a tightrope. If the developers get too much power and influence they will start building space stations when renovating a Volkswagen Golf will do. But if the project managers get too much power and influence then innovation stops and there is an obsession with the ‘on time’ and ‘on budget’ points of the triangle at the expense of the third one, ‘quality’ (or what I prefer to interpret as ‘doing the right thing’).

I draw no conclusions from this, but it gives food for thought.

I have recently found myself having to restate a couple of realities of the software development process. Not a problem, except that I seem to have to do it a bit more often lately. I’m not sure why this is particularly; maybe it is just in response to the usual day-to-day events.

If you’re interested, these are they:

  • #1. “‘Analysis in progress’ doesn’t just mean ‘Business Analysis’. It can equally mean analysis in all of its many forms – data analysis, systems analysis, or simply a developer looking at code”.
  • #2. “The developer’s role isn’t just about building new features. Often it is about helping the team understand what apps we already have by looking at the code, discovering how it works and what it is capable of. Very often this needs to come BEFORE requirements and features are defined”.

Both of these realities are linked. Defining requirements and features often needs some form of technical investigation and analysis to understand what we already have. There maybe portions of our applications that nobody understands – even the stakeholders and product owner. They may well look to IT to help them shape what is to be built. Some people throw their hands up in horror at this idea as if it represents some terrible failing or a ‘problem’ to be ‘solved’. This is rubbish. Far from it. It contributes to the problem solving and helps shape the features. This is a good thing.

I can illustrate this with a recent example. One of the applications I support – a contract management system – developed a weird fault whereby certain data on the contracts seemed to ‘expire’ and throw strange error messages after about 5 days. To get round this problem the users found a work around – the data in question was rekeyed with a slightly different names. This worked, but resulted in duplicated data quite apart from unease about why it was happening at all.

Much time was expended re-understanding the application and considering what might be causing it but everyone had drawn a blank.The users had no clue and many were new.

My theory was that because it was a contract system and the contracts had to go through various workflow statuses maybe the error was because certain activities hadn’t been done in time (i.e. within the 5 days) and the contacts were failing validation as a result. The message was somewhat vague.

At the stand-up I asked for a developer to be allocated. But I then got into a weird loop whereby both the developer and development manager wanted user stories and scenarios. I explained that we don’t have that yet because we don’t understand the problem. “But we need a story before we can start” came the cry. “No we don’t”, I said. “We need to understand the problem first. I can demonstrate it, but someone will need to look at the code”. I restated points #1 and #2 above and after some further battling I eventually got a developer allocated.

I could have written a story, of course. I could have said

“as a user I want the system to allow me to create contracts”

But what’s the point? It doesn’t get us anywhere.


You might be interested in the outcome of this?

Well, it turns out that the application was built in such a way that data was held in memory at the application (not session) level and not everything as being written to the database correctly. Because data was held in memory, everything appeared to work OK. Nothing untoward. The ’5 Days’ phenomenon was because the server recycled its memory every 5 days. This meant that when a user accessed a contract again after 5 days or more, the app would no longer have it in memory. It would then go back to the database, find information missing and throw an error. Nothing to do with the status of contracts. Nothing to do with anything around the business process or how it ought to behave.

Critically, there is no way on earth that either a Business Analyst or an end-user could possibly have discovered this outcome. It was totally different from any of our theories. Therefore the idea of writing a feature for it in advance, before the developer starts work, is totally banal. And as it turned out, no feature was even needed or written. All that was needed was some bug fixes supported by a couple of extra scenarios added to existing features.

A successful outcome but frustrating that it took so long to get there.

A copy of ‘Computing’ magazine turned up in the post-in box earlier. It wasn’t addressed to me, but to someone that had left 3 years ago.

I was stunned a) that it still exists – I haven’t seen it lying around on desks like you used to for ages. Years possibly. And b) how thin it is. Back in the day, Computing used to be A3 size and nearly the thickness of the average novel. Now it’s A4 size and about the thickness of the church magazine that drops through my door once a quarter. Not sure what to make of this really.

Oh, and it’s £4.99 a copy nowadays….

It’s ironic isn’t it.

Newspaper journalist criticises a major corporation (NBC over their coverage of the Olympics) and their Twitter account is suspended.

Meanwhile other Twitter users can fall victim to abuse and bullying to levels where the police need to get involved, and nothing is done.

There is a freedom of speech issue here. Possibly. But freedom of speech doesn’t give you the right to abuse and bully people.

What to do about it? Well, I could probably fill you an hour of discussion about it. Suffice to say that social networking sites need to wake up and realise they are no longer back-bedroom cottage industries but multi-million pound enterprises with influence and power. And with influence and power comes responsibility. And with responsibility comes some form of ‘policing’ and custodianship of what goes on.