Soluble problems

I’m very aware that I should put keywords in my blog. I’m also aware that I’m not attempting to monetise my blog. Anyone who reads it regularly, leave me a comment and I will be most grateful. Anyone who doesn’t read it regularly: you’re missing out.

I was comparing the fantasy of Agile management to the joys of converting a house.

Firstly, no matter how tightly you plan your project, it won’t work. The tyres get punctures, the render doesn’t go off because it’s cold, the plaster sets too quickly because it’s warm and so on and so on. One of the illusions that computers peddle is that values are fixed and unchangeable. Over years of experience one discovers that an apple this year is not the same as an apple last year: it may be smaller, sweeter, less common and so on and so forth. In the same way, programmers get ill, libraries get updated, life turns out to be a little difficult. It’s fine if you’re building on a greenfield site, but in the real world you may not be.

So we are dealing a non-representative series of events. Estimates are based on normal – that frictionless set of billiard balls or that perfectly rational economic creature… Life is imperfect, unbalanced, frustrating, and driven by chance. People on the top want to believe that it is driven by skill. They wish to confirm that it is their qualities that have given them their privilege, and others’ failures that have denied it. When talking about becoming a premier league footballer, people are willing to admit that some people are born with more talent than others. You rarely hear the fact that given a couple of X chromosomes, you’ll never make it. One sperm over another. Your chances ruled out, just like that.

Given the innate unpredictability of life, you need a reserve fund to cover the likely overruns in time and cost and temper whenever you’re planning a project. You also need a contingency plan.
This is one of the things I find most interesting. What do you do when a project has overrun? At what point are you prepared to say “pull the plug/cut the costs”?

It is my belief that life is much simpler if you have a hard deadline, chosen in advance, such that when you go over it, the project is pulled automatically. I would be curious to see how many things would get sacrificed if you knew that at fifty per cent above the original estimate, or at twenty per cent above the original time, consequences dropped in.

When I was in a partnersip, I rekember bidding for a contract. We honestly told the buyers “It’s not possible to do y in the time, but we can do x”. We didn’t get the contract. We were correct, of course, but people want to hear that they can do y in time t. Anyone who says “No” will lose out to anyone who says “yes”. You therefore need heavy penalties for misleading on contracts.

There is less temptation to gain a contract bby being over-optimistic if you know there is an automatic penalty for getting it wrong. But how may customers prefer illusions to truth?

Life has been busy lately. I’ve been revising the test schedules; not my absolutely favourite thing but better than a poke in the eye with a blunt fish. After the first desperate loops round the build, build broken, build buggy cycle, we have reached the stage of catch-up that we should have been in to start with, where features are being cleaned and polished, and software updates are being released every couple of days.

Apart from work, I have bought a house, and have been using Inkscape to plan the structural changes. It’s a nice tool. I started using Autocad Architect, because I can get it free as a student, but it isn’t merely using a sledgehammer to crack a nut; it’s using a Boeing Dreamliner to commute down the road to work. Yes it’s possible, and no doubt once it’s all set up it would be quicker than walking, but the learning curve is so steep and time-absorbing that I’ll just slip my shoes on for now.

OK, why do I like Inkscape?
It’s pretty basic, but it’s a proper vector graphics program, and it has all the things that I like using, in terms of converting objects to paths, grouping, layering etc. It lays things out properly with co-ordinates, and gives you accurate measurements.

There are some things that I’m pissy about – such as the way it seems to scale things proportionately when you don’t want it to, and I look forward to discovering about using 3-D stuff.

You can import bitmaps, and export bitmaps, so I’ve done some beautiful scale drawings of walls and windows so I can do accurate sketches of the planned mural.

All right, I admit it. The whole Inkscape exercise was a procrastination. It enabled me to spend a whole evening doing scale drawings. Possibly even two, and I haven’t done a single sketch on them. I have, however, borrowed a nice large book of tree photographs from the library. Get me!

I didn’t get the grant to attend the Cheltenham Science Festival (though I was runner-up, thanks UCL). As a result, everything I currently write is entirely unbiased and paid for by myself.

The first thing is a massive Yaaayyyy! And possibly Hurrah, hurray, hurrah. We have released. Doctor’s surgeries all across the land are getting their beautifully designed boxes, or their download invitations, and installing OUR software on their systems. Ian and Mr Grumpy are busy de-bugging as fast as they can, ready to release an update straight away, but marketing and sales are hap hap happy. Gavin and David are cheerful for the first time in weeks.

Obviously one of the things that sells the software is the way you can analyse your data. So you can see hours of work and rotas in pretty little patterns. In theory it will even calculate the nurses and doctors rotas for you. You can connect it to your appointments system and see who works hardest and spends the most of prescriptions and so on and so forth et cetera et cetera et cetera. GandD’s cunning plan is to allow people to register their data (anonymously) and see how it compares with other people’s data

The question is then what do you do with the data. As I’ve mentioned earlier, quite frequently, there are people who change their mind because of information, and people who don’t. This may be for two reasons. One is that well-known problem (or achievement) of human psychology; that we prefer information that backs up the position that we hold. We look for facts that support our viewpoint, rather than facts that will disprove it. This is why the null hypothesis is such a fabulous idea and is more common in myth than in reality.

The other problem is that the data may be useless. Firstly, it may be data rather than information. Information is data which has been judged, and it takes a human to judge (or, of course, an omniscient deity). Given humanity’s penchant for partial information and prejudice, we would often prefer to pass our judgement elsewhere. Secondly, it may be useless if one can take no action based upon it. What is the use of information that cannot be used?

So maybe, it’s best to hide data. Leave it in its data buckets in the garage, unmined and ignored. After all, all that unused data will only clutter up the minds and computers of the people who have to look at it. It will distract them from the decisions that they wish to take.

Perhaps I should introduce the concept of small data. Instead of “just-in-time” information, “just enough” information. Let the rest of it sit around if people want to go fossicking through it because they have an idea, but otherwise, don’t encourage them to mess about with it. Concentrate on the things they want to do, such as where to go for lunch and how many times you can read the same detective story with a different title.

OK, how may of you have ever even heard of Shintaido? None of you? Yup, that seems about normal. If you want to find out more about it, google is obviously your friend – or if not your friend, at least your tolerated acquaintance who you can’t not invite to events of importance. You can find out about Shintaido by reading up on shintaido,co,uk or even shintaido.org.

Why I am mentioning a little-known, barely practised non-martial art on what is supposed to be a blog about user experience? Well, I went to the fortieth birthday celebrations of Shintaido in Great Britain this weekend, and realised that I hadn’t written much about experience.

We talk about experience as if it was all the same thing. There is the sensory experience – visual response, haptic feedback, aural stimulation etc. etc. but we don’t really use experience in the old way, in the sense of getting of wisdom. We don’t talk about the experienced user as the concomitant of user experience. Someone with experience might be someone who knows better than to pursue a path to the end. The experienced user might now when it is best not to bother. When we talk about dealing with the elderly, we are willing to consider their motor skills, their eyesight, or their cultural background, but we don’t value the experience that may help them make the decision not to do what we are asking of them.

Shintaido is about changing your experience of life. It’s not an easy thing today, you don’t particularly get transferable skills from it; although there are moments of pleasure, they are embedded in moments of severe embarrassment and occasional pain. You may make friends, but you may also meet people who you like and then never see again. In other words, it is like life, compressed into a weekend. You hope it has a purpose, but there isn’t an obvious one. In that, it is unlike most other pastimes.

If we are offering users experience, is it something they want to have? Often what we are offering is to make the drive to the supermarket or pleasurable, or faster. We talk about peak experiences as things that you can guarantee, without giving due consideration to the fact that people might arrive at the waterfall in tears, or with cancer, or too busy kissing to look at the view.

I honour the fact that most user experience professionals want to help people live their life. After a weekend of struggling with Shintaido, I would like to occasionally find a way of helping people make sure their life is worth living.

We have now reached the exciting stage of pre-release procrastination known as testing. This is, of course, a vital and money-saving period, full of return on investment and this and that.

There are several ways to test:

1. The developer tests their own code. They don’t want to break it, so they treat it the way that it is supposed to be treated, much like a museum curator unpacking the latest Ming vase on loan from China, with extreme diplomatic and personal repercussions if anything goes wrong.

2. The customers test. This stage can follow immediately after 1. The customer attempts to do all the strange things that they used to do with the previous software, and immediately breaks the new version. In doing so, they may also lose their own work, ideally something that took several months to achieve and which they did not back up before upgrading.

3. The software is tested before release, according to a pre-arranged test plan. This plan usually consists of going through all the things that broke it before (using examples provided by customers), plus checking that any new functionality does what it is supposed to. The problems with pre-release testing are that the examples of failure may have been provided years ago, and that part of the code is as solid as a rock, so you are tempted to skip – always forgetting that code may have been re-factored, and, like the river chewing its way under wharves, large chunks may collapse into the spaces that have been newly undermined.
The other problem is that when you are testing new functionality, you need to know what it is supposed to do. And quite often you discover that there are large chunks of let us charitably call it “undefined behaviour”. Ie, the developers made it up on the fly because they couldn’t get a sensible decision out of anyone else, did not document it, and have forgotten what they did. For best effects, you need several developers who have all implemented the undefined behaviour slightly differently in different areas of the software, but sometimes you can achieve quite good effects with one developer, working on different bits of code with long intervals in between, so they have plenty of opportunity to forget what they did last time.

I have spent today working through the test plan. It has been an exciting and rewarding experience. Obviously we have loads of dummy data in files so that we can automate the tests as much as possibly, feed it in automatically, write out the log, but for various bits of interface testing, we have to sit there and run the test by hand and see what happens.

And as always, I discover that it has been tested that it behaves correctly if someone puts in the correct information, but not if someone puts in the wrong information.

All I can do here, is offer you the joy of http://xkcd.com/327/ on the matter of dirty data. Yes, you happy folk out there, people can be malicious, or merrely drunk, or just lost. Be prepared.

So I have filled out all the little boxes in the spreadsheet and logged several more bugs.

Personally, I think it’s all to do with the user experience. Much like watching people have forty-seven cats put down their trousers – they do it so that you, dear reader, do not have to.

I am so tired of living in a culture where everything appears to be about grabbing as much as possible. It feels as if we are being encouraged to act all the time, that any action is better than no action, and the idea that goodness might be expressed in refraining from action is just seen as weird. So, in the spirit of Zen Buddhism, I will suggest some things not to do before you die.

Don’t try and get a tan. It’s much more relaxing to read inside. If you want to sleep, why do it in public?

Don’t wear a bikini. It’s not a great look, even for men, and the bits come off when you dive in.

Don’t get wound up by your boss. They’re going to die too. Maybe with more money, but it doesn’t  save you.

Don’t watch any of the amazing, highly-recommended TV series. Wait until they come out on box set and then don’t buy them.

Don’t put up shelves in your house. You’ll only put stuff on them.

Don’t write lists of things to do, or not to do. You end up padding them out with rubbish,

This is an obvious substitute for actually writing up anything about the software release. Jiri currently has three half-empty bottles of Diet Coke underneath his desk. This is not a good sign. Mr Grumpy has decided to sell his house and move into a caravan in his sister’s drive. I’m not sure if he actually means this or not. He claims that it is the only way he can get away from the badgers that are building a sett in his garden. GandD are spending most of their days closeted in the conference room. Can you in fact be closeted in a conference room? Caballing in the conference room? Anyhow, they are busy, either having meetings with each other or with a set of lovely lovely doctors who are very enthusiastic about the possibilities of Jeremy Hunt and the NHS reforms and how our software could do just they wanted if only they tweaked it a bit. I have a terrible feeling that this won’t be a case of feature creep but a case of explosion in the feature factory and there will be a massive recruitment drive shortly, swiftly followed by a massive redundancy drive. But hey, I’m cynical.

I’m still trying to work out how to stop Gavin coding. Well, not how to stop him, just how to lock him out of other people’s work. There was a very bad scene a couple of days ago when Ian discovered that some of the stuff that he had checked into the code management system had been checked out by Gavin and horrible things had been done to it. Basically it wasn’t a case of his ewe lamb being taken, it was more it being taken, dyed pink, dismembered, and then returned attached to the back half of a leprous rabbit.

I think I will draw a veil over the coffee room conversation.