Newbies are your friends

All programmers and testers share one weakness: they don't know what it's like to not be familiar with computers.

Easy to laugh - but in IT the equivalents to push and pull signs aren't so obvious.

(Cartoon from The Far Side, in case you live on another planet.)

I have a confession: for a long time, I couldn’t get the 3G internet to work on my smartphone. When I bought it six months ago, I could make calls and connect to wi-fi, but the mobile broadband stubbornly refused to work. I read the manual from beginning to end, trawled the internet, fiddled with every setting and swore at it, before I finally realised mobile broadband wasn’t switched on.  After all the times I’ve been showing off making things look easy that other people struggle with, I can consider this a taste of my own medicine.

But, embarrassment aside, that was a good lesson in what it’s like to not be a techie. As a late entrant into the smartphone market, I was getting to grips with things that are second nature to most users. To someone who is familiar with Android, checking 3G internet is activated is such an obvious thing it’s not even worth mentioning,^[1] any more than a locksmith would consider it worth asking if you were pushing a door with a “PULL” sign. But little things like this add up and can stop people using new products completely. This is where usability testing comes in.

The dreaded feature creep

Even in the best managed projects, feature creep is difficult to avoid. Here are my tips for how to reduce the risk.

Apologies for another quantum mechanics in-joke. But this explains a lot.

Right, I’ve been told off for starting too many blog entries with “I’m afraid this is going to be another moan”, so this time I’m going to try to be a bit more positive. My last post had a go a web designers often over-charge for websites, and people who actually pay them that much. This contained an observation that this can apply to IT procurement more widely, with an example of the notorious contracts for £3,500 per computer in some government departments. Having thought about this, it was a harsh generalisation.

Where government IT projects overrun costs, it’s rarely because a company charged a fortune upfront. It’s usually because the initial costs are cheap but the contractor charges extra for things like including additional features, or installing new hardware. In some cases this gets out of control, like ridiculous call-out fees for something as simple as changing a mouse, and that is a key driver to the argument that IT companies rip off Whitehall. But the IT companies do have a good counter-argument. They often say that if government departments ask them to do a simple task, and then keep changing their mind in mid-project, it really does cost that much to keep making all the changes. I have come across both scenarios in my time.

But if we forget these two extremes and assume both client and contractor are genuinely motivated to work together and keep costs down, the fact remains that controlling costs is an absolute bugger. It is very difficult to get every detail of a working IT system right when the system currently only exists in paper plans. The mistake that must be avoided at all costs is “feature creep”, where more and more changes are requested to software in development, until costs rocket, the original design is no longer fit for purpose, and if you’re the NHS – well, we know what happened there. But there’s nothing new about feature creep, so why is does this mistake keep being made?