Behind closed doors: Who's winning the title fight?

Are there any programmers left out there among all the "engineers" and "architects"? Our love of impressive titles is merely...

Are there any programmers left out there among all the "engineers" and "architects"? Our love of impressive titles is merely fuelling public scepticism about the IT industry, argues one of the UK's most experienced IT managers.

Hardly a week goes by without another newspaper headline of a major IT project going down the pan. Unfortunately, many of these disasters are government initiatives so it is you and I, the taxpayers, who will ultimately pick up the tab. Okay, it is not a new phenomenon, but it does seem to be getting worse as our society becomes increasingly dependent on the successful application of information technology.

Wasting millions of pounds of public money every week is bad enough, but I am more concerned with the cumulative damage being done to our reputation as professionals. Because we are professionals, aren't we?

After all, we have borrowed plenty of fancy-sounding titles from other professions to designate our IT functions. Job descriptions abound with "consultants" of this and "engineers" of that. The sad truth is that these impressive titles usually bear no correlation to the professional standing of the bearer. Sure, I know that we have many among our ranks who have legitimately earned the status of Chartered Engineer, and I am not picking a fight with them.

For many others, however, their job title is more likely to be merely a precious affirmation of their personal need for status. I am old enough to remember when our software developers were proud enough to be called programmers and analysts. Now it appears that everybody wants to be an "engineer" at least from day one - without putting in the time. They say that familiarity breeds contempt, and consequently
"Now is a good time in our journey towards professional maturity for all software launched beyond our company's private infrastructure boundaries to carry a software quality kite-mark"
Colin Beveridge
I believe that our over-use of prestige titles seriously dilutes their value.

I honestly wish therefore that we had the guts to limit our future exploitation of the label "engineer" to those truly worthy of it, by dint of their training, experience and demonstrable proficiency. Then it would mean something. Until then, it can only be considered an affectation, serving only to satisfy our collective aspirations of respectability.

It seems that I am not alone in this view. Given the present spate of high-profile public IT disappointments, our professional activities are being subjected to wider scrutiny by other bodies. You've probably seen the National Audit reports on some of our recent government IT debacles. I expect we may well see more in that vein before much longer.

It is no wonder, then, that the Royal Institute of British Architects has recently objected to our misappropriation of the term "architect" in a data processing context. Quite rightly in my view, as members of the RIBA have to genuinely earn the right for their recognition, whereas we are generally just badge-engineering our human resources.

Why should a building designer have to study and work for years to become an accredited architect, when a software person can appear to achieve the same "status" at the stroke of a keyboard on an organisation chart?

Even so, you are probably sitting there wondering why I am getting so worked up over job semantics. You may well be thinking that life is too short to get upset about sorry little trivia such as this. Especially those of you working in American corporations, where the filing clerks might be afforded the standing of senior vice president, administration.

What's in a name, after all? In a world where even the most modest Saturday shop girls can be called sales consultants, why can't we all be engineers or architects if we want to be? Where's the harm in it?

Well my point, as ever, is fairly straightforward. Despite the fact that we now have so many thousands and thousands of software and hardware engineers, we still seem to have difficulty in engineering more and more of our major IT projects. (Remember, this is where we were a few minutes ago, at the start of this piece?)

That is because it is not simply a matter of terminology. It is much, much more fundamental than that - it is about our basic approach to systems development.

The primary difference between Systems Engineering, as currently practised, and "real" engineering is that our real engineer and real architect counterparts not only have to establish their professional credentials before accreditation, but they also usually put their personal reputations, and thereby their future livelihoods, on the line with each project they undertake.

For example, would you commission an architect to design and build your new headquarters if their last two buildings had collapsed? Or, if you needed a bridge, would you use the guys responsible for the infamously wobbly London Millennium Bridge? I think not. To ignore such strong evidence of past mistakes in the hope of future success would be considered financial madness, notwithstanding the safety issues.

That is why construction industry professionals are expected to certify that their edifices meet generally accepted criteria of quality, suitability and durability. Furthermore, there are appropriate supervisory bodies to endorse and sanction the abilities of the tangible service providers.

Yet these rules of integrity and accountability do not seem to apply to the so-called architects and engineers of our software industry, who remain free to repeat their past failures ad infinitum. A sad indictment, perhaps, but there are too many examples of failed projects for us to continue denying it.

As I said earlier, our society is becoming increasingly dependent on the application of information technology. This means that aspects of our everyday life are increasingly at risk from poor systems "engineering". Nowadays, it is difficult to avoid the pervasiveness of software, a lot of which is not only commercially important but also economy-critical, or safety-critical.

This worries me, knowing what I do about how some software is developed. It worries me even more because I recognise the crucible effect of mixing disparate software elements for the first time in an operational environment that cannot easily be simulated.

Twenty years ago a client asked me to develop process control software for their brick factory in order to optimise the kiln's use of gas. Not a difficult job in itself and their mini-computer (a dear old IBM Series/1) was eminently capable of supporting the application. The problem was, however, that they wanted to run the process control in parallel with their existing accounting software suite.

Fair enough, in those days a 96K mini-computer was a substantial investment for a SME, so I could understand their desire to sweat their assets by using it to the full. I refused to help them, however, on the grounds that I did not want to see half of Huddersfield laid waste by a previously undiscovered rounding error in the Aged Debtor's run.

This anecdote is not just a nostalgic indulgence on my part, it illustrates the persistent need for common sense and vigilance when applying technology solutions to a business problem. It is relevant today because more and more of our systems are using Web technology and are dependent on third-party infrastructure for execution. The Web is rapidly becoming a public test-tube for B2B software applications, and who can really be certain what the resultant cocktail will be like?

As peer-to-peer networking proliferates, our in-house helpdesks are certainly going to have their work cut out sorting out who did what to whom and how.

So, perhaps now is a good time in our journey towards professional maturity for all software launched beyond our company's private infrastructure boundaries to carry a software quality kite-mark?

I can already hear the desperate screams of "No way, José!" echoing around the country. "We don't need anyone to certify our work. We know best, trust us." Such is the arrogance of many in our industry. I know, because I am probably as guilty as the next person.

But in the everyday world of physical construction, we readily accept the need for independent validation of work in progress as well as the superficial appearance of the finished article. Property developers are not given carte blanche to exploit their hard-won planning consent. Once construction is under way, the appropriate local authority is obliged to inspect all new building works at key stages for compliance with standards and regulations. This is done to protect the common good of the public at large.

This system obviously works, and works well. Why the hell can't we translate this to our own industry then?

Is it too extreme for us to ensure that all government technology initiatives are independently assessed during development? I would much prefer to see routine health-checks rather than the regular autopsies we have now.

Call me a cynic, but PRINCE project methodology should make it fairly easy to adopt this form of sanity checking. Presumably, what seems to be lacking is the willingness to expose shallowness of thought, and the inherent deficiencies of the present process. As an interim manager, I often find that using a fresh pair of eyes is the quickest way of diagnosing problems and avoiding pitfalls.

So why can't we have an effective independent body to verify major technology investments? Call it the Software Audit Agency. I'll bet this would be good news for shareholders and taxpayers alike. Any lawyers reading this are probably getting excited, too. Seriously, it would only help to improve the overall quality of our information technology.

How many times do we need a virus such as ILY or Code Red to remind us how intertwined our software world is becoming? The Software Audit Agency could look out for susceptibility to virus attack for our economy-critical applications. We all know how much easier cheaper bugs are to eliminate if you catch them early enough in the development cycle.

Until we start to put some credible engineering rigour, discipline and accountability into our public IT projects, we should accept our present status as very well paid technicians. It's time to put our hands up and drop the delusions of adequacy - some of us really are more like jerry-builders than architects.

If that last statement upsets you too much, look in the newspapers and see how many successful public IT projects have been reported in the past year.

Colin Beveridge
is an interim executive who has held top-level roles in IT strategy, development, services and support. He has held posts at a number of leading corporations, including Shell, British Petroleum, ICI, DHL and PowerGen.

[email protected]

Read more on Business applications