Devil's Advocate: Is faster better?

They say change is a good thing. Yet when it comes to IT skills and processes, there is a real argument that we should question our recent 'progress', argues Martin Brampton...

It is a cliché to claim the only constant is change and that change is forever speeding up. There are deep cultural reasons for the urge to change but for the moment I am more interested in some more superficial questions. Does change really deliver benefit? Are we really doing things faster?

Perhaps there is an argument that change brings advantage, irrespective of the nature of the change. Could it be that the latest management fad is merely a way to unsettle people? Anything that causes us to examine what we are doing has the potential to spur us into finding better ways to work. Without a new idea to excite us, though, we get bored with questioning our familiar practices.

There is support for this view from the tendency for change to be cyclical. Not so long ago, devolvement was all the rage. For IT this meant splitting up powerful central departments and distributing skilled staff to separate organisational groups. Each separate group determined its needs and priorities and deployed the technology that served it best.

But then integration became a priority, so much so that the term enterprise application integration - or EAI - had to be coined to define a whole sector of the technology business. In most cases, scattered IT specialists were brought back into a centrally managed team.

Nowadays, outsourcing is a powerful trend. In some cases, there are persuasive reasons for concentration of specialist skills where they can serve a large number of client organisations. Yet in other cases, it is not clear why a bunch of people will do a better job if somebody else employs them. Practical experience demonstrates that creating and managing an outsourced contract is extremely challenging and obviously creates overheads that work against hoped-for benefits. Will the outsourcing movement eventually run out of steam, only to be challenged by the revolutionary idea of setting up an in-house IT function?

Last week, I was involved with some arguments about change control. A software vendor wanted direct access to its installed software and the related database, with a view to bypassing the client's regular change control procedures. The client was justifiably wary of this move, despite claims that it would speed up resolution of problems. That started me thinking about what is really speedy.

Years ago, data communications meant taking a box of punched cards in a taxi. Disaster recovery was picking up the cards off the pavement on a wet November evening and trying to get them back in the correct sequence. Software developers considered themselves fortunate when there was one opportunity each day to compile and test a program under development. These days it is normal to edit source code directly and to compile it interactively or even incrementally in real time.

Now although I would not want to go back to carting boxes of cards around, I have to question whether we have gained much. When computer access was strictly limited, far more effort went into thinking about the correct operation of a program. In a healthy development environment, each step towards the creation of new software was carefully examined. The result was legacy software, and while the term was invented to disparage, the fact is that it continues to be used because it is reliable and efficient.

In general, the quality of software is critically dependent on the skill with which the problem has been abstracted. A poor abstraction will leave many exceptions and a lot of extra error prone code. Conversely, a good expression of the problem will handle most cases as normal and will be relatively easy to modify in the light of new requirements. The design of a programmable solution to a real life problem is the key skill for IT and it depends far more on clear thinking than anything else.

So, in the practical case that confronted me, I was unsympathetic to the idea of speedy software modifications, preferring the safety of change control. More haste, less speed!