Caution: software development under way

Software development work has admirably high professional standards. Unfortunately, developers find it a lot easier to state them than to stick to them.

If your development team is one of those that lives up to the most exacting standards, this blog post isn’t for you. If, on the other hand, an IT department or software supplier near you is falling short of the levels of professionalism you expect, I hope his overview may give you some pointers as to why.

Estimates, guesstimates

One of the extraordinary characteristics of developers is their ability to estimate the likely duration of a job. It’s astonishing how they can listen for twenty minutes to your description of what you want a piece of software to do, and then tell you exactly how long it’ll take to develop.

Afterwards you may want to get an independent and possibly more reliable estimate, say by slaughtering a chicken and consulting its entrails.

At any rate, multiply the estimate by at least three. This is because the developer will have left a number of factors out of account.

• He – and it usually is a ‘he’ – already has three projects on the go. He’s told you he’s fiendishly busy, but that won’t stop him estimating for the new job as though he had nothing else on. Why? Because a new project is always more interesting than one that’s already under way.
• He’ll make no allowance for interruptions, though he knows that his last three releases were so bug-ridden that he’s spending half of every day dealing with support calls.
• He’ll make no allowance for anything going wrong. I suffered from this problem in spades. I remember very clearly the one project I worked on which came in less than 10% over schedule. It’s the only one I remember when I’m estimating. All the others, which came in horrendous overruns, are expunged from my mind.
• He only thinks of his own time. For instance, he hasn’t allowed for documentation. Developers are part of a superior breed that lives by mystical communication with each other. Writing things down is like preparing a pre-nuptial agreement: it destroys all the romance. As for QA, well, yes, of course there should be some, but only to confirm that the software is bug-free. A few days at the end of the project. You object that there may be some feedback, as QA finds errors that need to be fixed. Well, yes, add a few days for that too, but believe me, it really isn’t going to hold up the project.. The Red Queen in Lewis Carroll’s Through the Looking Glass claimed ‘sometimes I've believed as many as six impossible things before breakfast.’ If you want to emulate her, start with ‘you can get good software without extensive QA.’ 
• He hasn’t actually seen a specification yet. That one deserves a section to itself.

Specifications – who needs one?

Once you’ve told the developer what you need from the new system, he just wants to get on with it. He doesn’t want to waste time writing requirements down. He wants to get on with cutting code.

Perhaps I should have written ‘Code’, with a capital ‘C’, since it has the status of near-sacred text. For those who don’t know it, it’s made up of large blocks of completely opaque programming language. Some unorthodox developers believe in including the occasional line of natural English, so-called comment lines, with the aim of explaining to someone who might come along later just what the code was intended to do. To purists, these lines just interrupt the natural flow of the Code. The next guy will be another member of the sacred band and will work out what the Code was intended to do, just by reading it and applying his mystic intuition. Comment lines are just boring, like specifications.

It’s true that specifications can be deadly. I recently saw a 35-page text covering work that we actually carried out in less than five days. The spec contained at least one page marked ‘This page intentionally left blank.’ Whenever I see one of those I want to scribble across it ‘why wasn’t this blank page intentionally left out?’

That kind of thing gives specifications a bad name, but something tighter and more to the point can be really useful. It can at least ensure that we understand the same thing by the words we use.

Once I came across a system which assumed that ‘Non-Elective’ meant the same as ‘Emergency’. Terribly embarrassing when you have to explain to a Trust why its emergency work has shot up while its maternity work has fallen to zero along with the tertiary referrals it used to receive.

Of course, if you’re working with people who just never need anything like that made clear to them, you may well be able to get away without a proper spec. One word of warning though: it’s really difficult to see how you can test software to see if it’s behaving properly, if you haven’t previously defined what it should be doing in the first place.

It’s about the reporting, dummy.

www.CartoonStock.com

Ever since Neanderthal times man has been expressing himself by means of graphics. So why in the twenty-first century are IT professionals finding it so difficult to understand the need to do the same?

Most users of healthcare information think its aim should be to help take better decisions about care delivery. So they might want to see a range of indicators all included in a single dashboard-type report. They may want to be able to drill up and down, say from a whole functional area within a hospital down to individual clinical teams to groups of patients with similar diagnoses. They may want to see values for the whole year or for a single months or, indeed, for trends across several months. They may ultimately want to get down to the level of the individual patient records behind the general indicator values.

Now many IT people will simply yawn at all this. Have you ever come across the term ‘ETL’? It means extract, transfer and load. The most exciting for an IT person is ‘Extract’. This means he’s looking at someone else’s system. This is a challenge, because the probability is that the teams who built that system didn’t bother with any comment lines or documentation – they’re kindred spirits, in fact. So it’s a battle of wits. Our man is hunting among tables with names like ‘37A’ or ‘PAT4201’, trying to identify the different bits of information to build up the records he’s been asked to load. And it’s a long-term source of innocent fun: system suppliers are quite likely to change the structure of their databases without warning, so that our developer can go through the whole process again every few months.

Next comes Transfer. Well, that’s a bit less absorbing though it can still be amusing. Your tables, for instance, might hold dates of birth in the form ‘19630622’ for 22 June 1963. The system you’re reading from might hold them in the form ‘22061963’. You can fill some idle hours quite productively writing the transfer routines mapping one format to the other.

Finally, there’s Load. Well, OK. Yes, it has to be done, but it’s not half as exciting. Get the data in, make sure that it’s more or less error-free. A bit fiddly, but there you go. Once it’s finished, your work is done.

Have you noticed the omission? We’ve done E, T and L. There’s been no mention of ‘R’ – Retrieval. What matters for IT is getting the data in and storing it securely. Making it available for someone else to use? Come on, that’s child’s play once the data’s been loaded into a database. It’s someone else’s department altogether.

Sadly, that’s not a department that is always as well staffed as it might be. That’s why hospitals are awash with data but short on information. That’s why we’ve spent billions on information systems with so little to show for it. That’s why clinical departments that want to assess their work build their own separate systems, creating new silos of data.

Unfortunately, investment isn’t as easy any more, and we certainly can’t keep making it without the real promise of a return. It’s great to see developers having fun, of course, but wouldn’t be even more fun to deliver systems that really worked and that healthcare managers really wanted to use? Systems that genuinely delivered information for management?

Sound utopian? Maybe it is.

But since it’s pretty much the minimal demand any user should be making of an information system worthy of the name, maybe it’s time we started insisting on it a bit more forcefully.