Archive for October, 2008

Someone was telling me recently about their experiences with BT Vision.  This is the on-demand TV service that hangs off of your HomeHub/Broadband service.  To cut a long story short, it seems to have one problem: it doesn’t work very well. Even when it does, downloading a movie to watch can take about 3 hours or more.   And here lies the gamble you have to take: Although I’ve always found BT Vision quite an attractive proposition, you can never really find out how good it actually is until you have it installed and by then it’s too late.  The conversation drifted onto on-demand TV generally, SKY, Cable, and so-on, and I remembered an article in the Guardian recently where Emily Bell said that the only true ‘on-demand’ is the DVD box set. Considering that even if you get a reliable service out of BT Vision you could go to HMV and back in the time it takes to download a movie, I think she might have point..

On a related note I was also chatting to someone about opensource software initiatives. They said something about ‘wouldn’t it be great to extend the ideas to the entertainment and content industries’.  This conversation got rather more heated and impassioned than the woes about BT Vision, but this is a very much summarised version of what this guy was on about:

The traditional ways of developing software are coming to a close, with organisations looking to build systems using freely available tools and where the products are released into the market to others to build upon.   These principles could apply to the entertainment industry with public service content being available in the same way.

That’s roughly it.   There are a number of issues here. 

Firstly, on the ‘software’ point, I’m always slightly wary when people use the term ‘software’ to describe the development projects they are engaged in.  Software – to my mind – is something you go out and buy (or otherwise aquire, I guess) – and that implies a slightly different approach to building a system internally.  Adobe build software. An internal information systems operation is not Adobe: It performs quite a different role with different motivations.  Many organisations (probably most, actually) don’t build software. They build Systems to forfil a specific purpose.  This is an important distinction and not just petty pedanticness and it’s important to keep the differences in mind.

On the ‘open source entertainment’ note:  This throws up various issues.  Firstly, the product of our creative and entertainment industries isn’t freeware.  It is mostly owned by someone – somewhere – and they are going to expect payment for its use and rightly so.  It isn’t for the technology industries to dictate how someone else’s property should be used.  Obviously negotiation and innovation mean that that content can be made available in new ways but this should be on the artist’s or owner’s terms.  If you have a book out you’ed expect a royalty cheque each quarter.  You wouldn’t want someone unilaterally deciding to distribute it for free just because they’ve knocked up a cool software tool capable of doing so.  Where technology comes in is that it can provide information about what is available and enable ways of getting it.  You have to remember that just getting information about what exists is a breakthrough. Remember the books example: There were consulting companies in the late 90s telling people that books were dead.  Complete nonsense of course – the internet resulted in book sales going up. That’s mostly because people can get information about whats out there and don’t have spend hours looking. So no. Books are not dead: And nor are high streets, radio, movies or anything else.  Nor, most importantly, is television (even if the so called ‘visionaries’ and ‘futurists’ still seem to insist that it is). The key is trying to unlock what we already have and getting it to people, but there revolution – if there is one at all – is in finding out what we have (and making more of course):  Not in the distribution – certainly if BT Vision is the benchmark..

Astonishingly, I’d said all of this during one pint….

Someone pointed me in the direction of this article recently.  Certainly thought provoking:


What it doesn’t mention, though, is anything about how project funding is allocated.  To me, this has a huge bearing on how projects are structured:  If project funding is allocated in one upfront ‘lump’ (what I often refer to as the ‘Purchase Order Culture’) that implies a large upfront analysis exercises to determine what the overall budget is going to be.  This article concentrates on a war which to some extent need not exist – both agile and waterfall both have some good and some bad points.  The war (if you want one) is to do with how finance is allocated and why it is allocated often with little insight into what the project will eventually turn into.  Even on an ‘agile’ project, they key decisions may already have been made – perhaps even by finance people.  You just haven’t been privvy to them.  So if the budget, timescales, milestones and overall direction have been agreed already (and sometimes a long time before) your so-called ‘agile’ project is little more than window-dressing.  No wonder it’s difficult to get business or user buy-in sometimes… 




… really? Well try telling that to most media executives. Or even to people you meet on the bus or in a bar.

I came across another maniac using this phrase in an article in one of the papers the other day. 

I couldn’t help but wonder how this statement squares with the fact that Radio listening seems to be as strong as it has ever been, and TV viewing is higher than 10 years ago:  (scroll to the bottom) and 

It just goes to prove that if you want to keep in touch with what is really going on, you have to treat the opinions of the so-called ‘visionaries’ and ‘Futurists’ with some degree of caution…

I recently invested in some Powerline Home Plugs. These are the little known devices that turn your electricity main into an ethernet network: You can then site your equipment anywhere in your house, with little speed degredation or need for cabling. I went for the Solwise mains-through version – which mean you can plug other mains devices through them and avoid tying up a wall socket.  Linksys, Netgear and all the rest of them have home plug versions too, but not the mains through variety.

They aren’t cheap – they cost about £55 and you need a minimum of 2 – but so far so good.  I had to reset one of them after 3 days, but on the whole they do the job.  

Computer data over the electricity main reminded me of years ago when I was working for a computer company where the managing director had previously been involved with this technology.  He had apparently worked on a research project that entailed sending computer data over the wider electricity grid. At the time he was working on it, I guess it would have been pre-internet, so I assume (if it had come to fruition) would have amounted to a way of making Prestel or similar applications more available, or the new-fangled cable TV networks.  The prospect of just plugging in a wall-socket device and being online is an interesting prospect – just make sure you don’t plug anything in to the wrong socket of course!!!

This article inadvertently ended up focusing on Use Cases rather than UML as a whole, but is still important. There is alot more to come, though…

Every now and then the subject of UML with agile projects comes up.  My view on this is the same as it has always been: UML has a big part to play, because (a) UML is a communication language and is well suited to help you get you message across in a meaningful way, and (b) the finely-grained nature of user stories, backlog items and acceptance tests often doesn’t give people the context or overview they need to understand the bigger picture.  As systems grow ever more complex and connected, this bigger picture is important. 

Some people insist in misinterpreting a statement like this as if it is almost some act of heresy:  An attempt at imposing a draconian iron-fist of bureaucracy over things; a pollution of the agile principles; a return to waterfall.  Crazy.

Where the difficulty – and the argument sometimes – comes in is that whilst there is a bigger picture that some people might need to be aware of, not everyone necessarily needs to know it. Most members of a team don’t work on everything, and whilst the agile principles include the spreading of knowledge, rotation of team members etc., people will still need to get up to speed in the first place.  If your project has allot of legacy baggage, systems integration, complex data, data quality issues and so on, this isn’t going to be easy to understand or to explain.  Also, spare a thought for those new to the team or department or perhaps new to the company entirely.    Obviously if people want to understand the bigger picture and take an interest in why they are building what they building in that particular way, that’s great, but you can’t necessarily force people do that, though. Just as you can’t force people to go to the department away day, or to attend corporate presentation events.  It’s better if they do, but it’s just not up everyone’s alley.

I don’t think there is a major issue with the techniques: nor is there, really, a major intellectual debate to be had about how UML slots in.  You can slot UML relatively easily into any project: It’s simply a communication tool. Moreover most of the key techniques in it have been around for decades, and certainly were around before the UML itself.

Let us consider something which is becoming more of a hot topic – accessibility. Traditionally, many people have viewed this as something of a side-issue; a bolt-on task performed by a ’specialist’ in combat-trousers and a strange t-shirt.  I would argue, though, that accessibility is actually just a facet of good design and that considering accessibility actually forces you into thinking about your system in a clearer way. 

Consider a simple web page where you have to choose a product, choose a quantity and add it to a basket.  I did this just now.  The site I was ordering from sells relatively few products – in the region of about 20.  The ordering page was relatively straightforward and on the face or it, the initial thought going through one’s head is this story would read something like ‘As a public user I want to select one of the products and provide a quantity so that I can add it to the basket and continue’ (or whatever else). The story is very straightforward.  It’s a drop-down list, a text box and a submit button. Nothing unusual there. Or is there?

Apart from the fact that it assumes we only add one product at a time to the basket; we have assumed that our page will allow one of only 20 or so products.  It all makes a kind of sense. But what happens if we are later told the product range will now contain things not previously available. We will be looking at in the region of 2000 products.  Where does that leave us?  It’s not outrageous to expect the company to start selling more products.

Well, our page won’t blow up with 2000 products, but wouldn’t meet the accessibility guidelines. We need a way of reducing the list of products into smaller more manageable lists or sets somehow.  There are a range of ways of doing this: perhaps an intermediate search screen, or some kind of browse facility.  This in turn might show up data quality issues, the need to consider search performance and perhaps ways of categorising and grouping the products using data items that don’t currently exist, and so on.  Allot of this stuff is almost a science in itself.

This is a simplistic example, but the point is that our simple ’select a product and add it to the basket’ story conceals allot of detail that isn’t necessarily obvious and that the users themselves might not even have considered.  In my view, this is where Use Cases add significant value: If written well they enable us to join up several smaller stories, provide us some context, and help accessibility designers and others to plug in to the project relatively easily. 

The following diagram attempts to represent this:

Note the following:

  • In Sprint 1 we have 4 features that have been scheduled, and these are mostly covered off by 2 Use Cases. These in turn have some supplmentary information but the information is quite different:  A List of agreed User Roles has been produced against Use Case UC-1, and a Wiki entry for Use Case UC-8.  
  • Use Cases UC-1 and UC-8 have been written in such a way that they reference the interface design wireframes:  In the case of UC-1, this details a screen or page containing 3 groups of screen elements which have been labeled A, B and C. These elements might pose their own problems, of course:  As we noted above, if elements A and B represent the enhanced Product Search we have be asked to build, there is likely to be alot behind this:  We obviously don’t go any further down than this though:  Certainly not to the field level – we can detail that elsewhere.
  • Requirements Group 2 has another set of Use Cases and these have been supplemented in a different way again.  In thise case Sequence Diagrams are appropriate: Perhaps there is a call to another system.
  • We have some features that don’t require Use Cases:  The functionality is understood well enough in itself.  Fine.

It seems logical to start with user stories as a “needs” capture, and then evolve the stories into use cases. The story is the placeholder for a later discussion, and the results of this will define actual goals for the system. To produce an agile Use Case, you simply need to provide a skeleton that can built on later – but not too late that you end up with more analysis than you have time to do.  Other interested parties, the accessibility designers, the corporate identity/brand people etc. have something of substance to work against. 

Alistair Cockburn quite rightly points out the danger of overlooking completeness There is obviously a need to unearth new and otherwise overlooked functionality that isn’t glamorous enough for the users to come forward with. This is life.  We’re not here to expect the users or customers to spoon feed us everything we need to know – we have to go looking. We have to influence their thinking.  So the completeness question is key: and NO, that doesn’t mean ‘Big upfront design’, ‘analysis paralysis’ or anything of the sort.  There is of course alot of opportunity to produce very bad Use Cases, especially since the Use Case descriptions aren’t actually defined in the UML. I’ve certainly seen many horrendous examples, and met people with an almost religious adversion to them as a result.  This is unfortunate – but in a way you can’t blame them.  The answer, though, is simple:  Produce good ones – human nature is such that that much lies in the presentation, with people quick to pass judgement. But the technique itself is not flawed at all: Try working at things before you write them off.

Obviously Use Cases are predominately based on User Interaction (though they can cover interactions between systems too).  For system-system interactions and the order in which data is exchanged or processed, Sequence Diagrams and State Machines are ideal. 

Clearly, not every set of needs or requirements in the system will afford the same amount of analysis and attention.  If you are working on an externally-facing web site aimed at marketing brands of breakfast cereal you will be in a very different position to those people implementing a content management system, constructing an interface to SAP, or engaged in a complex data migration as well as building more convential user interfaces.   

Of course, you may think that you can get the necessary detail illustrated above just by reading a set of User Stories.  All I can say is: Good luck.