When the solution becomes a problem

Due to the snow we've had over the past week or so, there have been a great many school closures in the UK, including our county.

On every hand, there are pointers telling us to visit this website to find out if our kids' schools are closed. How great that they have this facility. I'm assuming that the headteacher of each school is able to access the site directly to indicate closures. Great. So parents can go there instead of all frantically trying to ring the school and getting the engaged signal. Wonderful.

Except that, as soon as all the parents in the county tried to access it, it fell over! So the local radio station stepped into the breach and began announcing school closures. So good that they have a plan B.

Except that the radio was getting its information from the website, and the traffic on the server meant that the school representatives responsible for updating the website couldn't access it. So the information so kindly being supplied by the local radio station was not up to date.

We do know that the school bus service isn't running. This is a private service, paid for by parents. So we know that a good proportion of the students won't be there. Usually, under these circumstances, the schools are closed, but the problem with the server has made it impossible to find out.

For goodness' sake, when you build a solution, make sure that you have considered the logistics, and that it is actually going to be able to cope with the demands for the service it offers!

This is not the only example we see like this. The A&E (accident and emergency) services are in a similar position. When you hurt yourself, every signpost points to your local A&E. When you get there, you are likely to sit for 3 or 4, maybe even 7 hours waiting to be seen. While you wait, you can read the posters on the wall that tell you all the other places you could have gone - your pharmacy, your GP, the NHS helpline - all of which will no doubt have told you to come to A&E! Left hand, right hand.

When the millenium (foot)bridge was built in London, it had to be closed for repairs almost immediately because of the extent to which it swayed. The engineers announced that this was due to a phenomenon known as simultaneous footfall. When the designed the footbridge, they apparently didn't take into consideration the fact that people would be walking on it. Lots of them. All at the same time.

When we're designing solutions, let's consider the implementation aspect. The practicalities. The logistics. This is where it is very useful to have a friend on the inside (of the IT department). Unless the IT department knows what is envsiaged, they can do nothing to accommodate it. They also can't alert you to possible barriers to implementation.

It's also a good idea to include some load-testing in the battery of user tests you carry out on a solution before implementing it.