Coding Chickens

In a short break from our usual programme (while I finish writing up the details of my fast), I feel the need to explore some of the horrors developers face; if only to make myself feel a bit better.

Sometimes being a developer is rewarding, sometimes you get the strong feeling that you should be able to do more to help. Sometimes you get the feeling that you just can’t get people to understand that you are trying to help. You’re not giving long time estimates out of a desire to be difficult, you’re not trying to make something “sound more difficult than it really is”. You’re just trying to help.

Nowhere do I bump into this more than when managers congregate to work on ‘systems’.

A system is a nebulous thing, or at least it is before someone like me gets involved – I’m a systems developer, so I think in terms  outcomes and inputs, and minimisation of interaction. My job (which I am ok at, or so I’d prefer to think) is to take the fluff of a user requirement and turn it into a practical improvement. This unfortunately means that I bump into a lot of people who also believe that they can create systems.

I have the opportunity to watch this process of creation from a short range, and in one of the businesses I’ve dealt with for a very long time the effect is similar to watching a small clutch of argumentative chickens trying to work out a mirror. This mental image is far more amusing in the mind than it is in the flesh – as someone who really wants to improve an overall work environment, phrases like “Oh, I think we should have another form filled in and scanned before we let users do that” make my blood boil. At the end, there’s a lot of noise, some feathers in the air and nothing remotely looking like a system in place.

There are people in these meetings who squawk because all the other chickens are making noise, there are people who add redundant checks and measures and steps because they realise their own make-work may be reduced, and there are people who really shouldn’t be allowed to add their tortuous mental loops into the process.

You know you’re in the presence of the latter when the subject of outcomes comes up on the agenda. These people want to track and report on everything it seems. Mistaking visibility for control, they want to see “every stationary order under £15 for the year 2001” (a genuine phrase heard in a chicken-fest). What then unfolds is a system where a huge amount of ROD – my own coining for wRite Only Data – is captured. Every user, at every point in the process is suddenly burdened with entering data they may barely understand (or indeed know) into the system – resulting in a massively bloated interface that nobody wants to use. Quite simply, the clichéd ROD for your back.

Don’t get me wrong, I have some good clients relationships; many lasting over years where such happenings don’t take place, where the chickens are carefully cooped before a requirement meeting even takes place. One has even got themselves to the point where they are able to judge how long it’s going to take me to deliver their requirement – and how I love them and cherish them as a client, and how much more willing to stretch things we are when things go to the edge of the specification.

A waterfall is an elegant system for getting water downhill.

These people capture only the data they need, only generate the documents they need and only capture the data they need – and they can take advice about how best to organise these into an overall business solution. People who are of genuine value to their business are never worried about “systems” taking over their part in the organisation, they instead relish the chance to get away from the make-work and get on with their job – making the business better, and not carefully crossing off items on a printed report with a biro and a rule. This latter of course would be a firing offence in my own business!

Leave a Reply

Your email address will not be published. Required fields are marked *