I’ve noticed an equipment failure at work, and thought it would be serve as a nice illustration of some of the problems we regularly experience in IT.
What convoluted software based menace lies at the heart of our troubles? Well, none – this is a hardware issue actually – we can’t change the toilet roll on the toilet roll holder in the gent’s toilet. It’s not because we’re thick – we are by the very nature of the job we do creative souls who aren’t afraid to sit around and dream up both cunning and elegant solutions to the problems in our lives. It’s not for lack of trying – because it turns out most of us have encountered this issue, noted the problem, but only recently did we come together and face our collective shame.
Here’s the problem – some idiot, when they designed the toilet role holder, did so in such a manner that the centre piece that should be removable to enable it to be placed through the toilet roll tube is fastened into the assembly using hex bolts at both sides. End result, if you don’t bring a hex key with you, you’re not changing that roll.
My first thought here was to laugh at the engineer who designed it, who quite clearly had not ran his/her product through User Acceptance Testing for more than a couple of days, in which time the problem would have become self evident. It’s important, whenever you deploy any new system / feature, to keep the specification in mind, and to keep in contact with your users to make sure things pan out as they ought. If you don’t talk to your users, sure, you’ll still shift a few thousand units of your bog roll holder – but someone else will come along with new “Easy change” technology and take over your whole party. That sucks.
So I was feeling quite glad about the fact that some Buisness Analyst / Tester out there had dropped a bit of a clanger, when I started thinking a little more professionally. How had the engineer who designed the thing managed to get so absorbed (pun intended) in the problem of holding a toilet roll that they never stopped to consider how it might be changed? Had they become so set in their bunker mentality that they genuinely thought all office cleaners carry hex keys? For that matter, did they believe that the roll is always changed by cleaners – because it rarely is. How close was the engineer to the problem – did they really take the time to understand how their little contribution truly slotted into the whole “office based lavatorial services” system?
There are parallels to be drawn here between designing toilet roll holders and designing software – and as professionals we should not be above a little impartial self evaluation and criticism. Do we truly understand the customer, what they need to achieve, and how best to achieve it. We shouldn’t be afraid of saying “No” – there’s value to that and we can learn from it. Passing unit tests is not the same as passing THE test, and we need to pay a little more respect and attention to our colleagues in Quality Assurance when they tell us that although we’ve met the acceptance criteria, they just “don’t like it”. If our own people have reservations, what’s the customer going to think?
Another lesson here, pointed out by one of my colleagues actually, is that the engineer is not necessary to blame for toilet-roll-gate. Who’s to say that we haven’t ordered a product that is actually quite deliberately designed to be difficult to change? I’d imagine such toilet roll holders are common place in prisons for instance – who says we haven’t mistakenly ordered the wrong product? Slipping back to the parallel universe of software design, that’s something else we have to be careful of – Is what the customer is asking us to build really the best solution for all their problems? Can we do better? Can we engage with the customer, make improvements to the product, but still not have to make a version covered in blinking LEDs and switches just because they said they wanted it? Do they REALLY want it?
It turns out, we all have value in the process of software development. BAs, testers, developers, customers and the people who actually change their bog rolls (in other words, the users) all have an important contribution to make. Who would have guessed?
There’s something else to be considered here as well – because despite the fact that all our talented BAs, testers and developers in the office are now aware of the problem, no-one has tried to fix it. No “Easy change” roll holders have been ordered, and the people who have the power (of which we might only dream) to do that were not included in the conversation. Instead, we’ve agreed on our own little workaround procedure – we leave a few rolls on top of the cistern. How many systems out there in the field also contain such well intentioned modifications, and no longer function quite how their designers, their responsible managers, and their users actually expect? How much is that costing IT every year?