Steve Reeves: Software engineers need to take hard look at their profession

Photo / Hawkes Bay Today

There's been a lot of talk about consolidating "back office" functions in health services since the release of the ministerial review group's recommendations on revamping the health system.

The idea might be to save money by reducing duplication across the 21 District Health Boards and more than 80 Primary Health Organisations. But the prospect should be sending a shiver down our collective spine when it comes to the computerisation of patient records.

Seven of the boards are currently seeking tenders for the provision of such a system, which could be introduced nationwide.

The cost could reach up to $450 million, according to one potential tenderer, Australian company iSoft.

New Zealand joins countries across the world in seeking this particular holy grail - one single nationwide (or even global) format for patient records which renders them perfectly accessible yet perfectly secure.

Such a system is likely to remain elusive given the current state of IT capabilities.

Take for example the British Government's ambitious bid to create an overarching computer system for the country's National Health Service.

At €12.7 billion ($26.5 billion), it's been billed as the world's biggest civilian IT project. And seven years into the project it's already five years behind schedule, way over budget and fraught with controversy and technical and ethical difficulties.

Why do complex IT projects consistently over-promise and under-deliver? Partly it's because software engineering itself is a young discipline, without the processes and systems common to traditional engineering disciplines.

And partly it's because we all tend to have a rosy view of what software can do.

Most traditional engineers tend to build concrete things that you can see and touch, and can provide a model or diagram to show what they plan to do - what's called externalising design. And most end users have at least a rough understanding of what's feasible and what's not.

In software development, it's quite different. If an aeronautical engineer tells me that I can make the plane go faster by building mile-long wings, I know enough about the real world to say that's ridiculous.

But when a software engineer says we can build a completely secure national patient record system, I've got no way of laughing him or her out of court.

Lack of rigour in software development and inflated expectations of what's possible are nothing new. In 2004, Britain's Royal Academy of Engineering and the British Computer Society produced a joint report, The Challenges of Complex IT Projects.

It concluded that there was a worrying lack of professional competence in software engineering, particularly around managing complexity and risk.

It recommended better initial and ongoing training and called for the introduction of chartered status for senior IT professionals.

Five years on, the two bodies have just come out with another report - Engineering Values in IT - which says very much the same thing. This study takes a big picture view, isolating the difference between developing and using IT (a distinction often ignored in teaching computer science), and noting the strong parallels with the professionalisation of medicine in the 19th century as it moved from a craft to a discipline.

It's an apt comparison. As happened in medicine more than a century ago, professional IT bodies are now taking the first steps to regularise the profession. This year, the New Zealand Computer Society has begun the process of chartering IT professionals.

The new internationally recognised ITCP accreditation will require holders to provide regular evidence of upskilling, opening the door for training providers to come up with ways to teach good, science-based IT practice.

There may be an opportunity here to collaborate with the Institute of Professional Engineers of New Zealand (IPENZ), which already accredits software engineering degrees in New Zealand and has an interest in promoting professionalism within this up-and-coming discipline.

These are small steps, to be sure, but as a researcher and teacher of software engineering, I'm only too aware of the huge gap between the heightened expectations "out there" of what software can do and the reality of how it's currently produced.

Anything we do to close that gap, and bring truly science-based, engineering rigour into software development, will pay off in spades in the future.

The mathematical models researchers here and overseas are now developing to introduce this rigour into software development are another important step towards professional behaviour.

Software engineers should be using the best methods currently available, and not implying we can do more for our customers than we truly know we can.

So, just as bridge builders use mathematical models to ensure their bridge is up to the job before they start construction, so software engineers need to engage, and get educated, in the same sort of mathematically based methods - particularly in high-consequence projects where it's essential the software works. We just can't afford not to.

* Dr Steve Reeves is a professor in the Department of Computer Science and associate dean of Software Engineering at the University of Waikato. He is a Fellow of the New Zealand Computer Society and a member of the Royal Society.