Commentary: Design before you build...

There is an awful tendency in IT to take short cuts. This applies especially to software development, despite all the talk of engineering. It is as if an engineer building a bridge, faced with a big workload of welding, decided to use Superglue instead, so as to achieve an early delivery.

So it is gratifying to see that at least some people resist this damaging tendency. Recently, the Metropolitan Police force has distinguished itself by settling on an architecture within which it will constrain its systems to conform to consistent standards. Given the importance of policing our capital city, one can only hope that the design is sound and that developments will adhere to it.

For there is always a tendency to take the Superglue approach when it comes to project work. The typical project manager is wholly committed to making progress and overcoming obstacles. That is all to the good, until the design principles for the system start to be seen as obstacles. If deadlines are at stake, the temptation to abandon principles in favour of rapid progress seems almost irresistible.

Yet it should be resisted, at least up to the point where the design principles can be shown to be infeasible. And that brings us to the important question of the quality of design. It is an area that receives too little attention in a world that emphasises feature lists and time to market. But good design is the essence of sound systems.

Important judgements are made in the design of a computer system that will be fundamental to its usefulness. Too much abstraction, and the system will be impossible to implement. Too specific a solution, and it will most likely be obsolete before it is implemented. The best designs solve immediate problems, but are also flexible and robust enough to be adapted for the inevitable future changes.

Recently, there has been a good deal of hand wringing over testing, or rather the lack of testing. Like design, though, testing is not only a matter of how much, it is also a matter of how good. Testing, too, is tightly linked with design, depending heavily on the quality of the latter for its effectiveness.

Black box testing has a useful role and good testers will probe a system hard to find weaknesses. This is significantly more powerful if tools are used to make tests repeatable, saving effort as failed software is remedied and retested. Testing software without knowing how it was constructed has severe limitations all the same, and unless the software is already pretty sound, it will only uncover a proportion of the faults that are lurking in the code.

Initial testing of units of software is only effective in relation to an understanding of its detailed design. It must concentrate on boundary issues where the behaviour of the software should change in specified ways. The better the design, the fewer the boundary issues and the more generally applicable the software.

But then, the larger scale quality of design becomes critical as software units are brought together. Design principles that stress reuse are well known but have often been ignored in the heat of project work. There are difficult organisational issues to solve if long term reuse is to be achieved. Yet many projects are large enough that good design will allow extensive reuse within the project, contributing both to productivity and quality.

Finally, there is the implementation architecture, which is the area recently addressed by the Metropolitan Police. Ensuring that systems are implemented within an agreed structure is a vital element for longevity, reuse and practical maintenance. Most systems have a surprisingly long life and before they are discarded are used in quite unexpected ways.

We cannot ignore the time pressures that arise because a project is needed quickly. But it is no use wringing our hands about unreliable, inadequately tested systems if we have not tried our utmost to spend enough time and intellectual effort on the design stage. Quality is not something that can be retro-fitted.

Martin Brampton Martin Brampton is founder of Black Sheep Research (www.black-sheep-research.co.uk), an independent consultancy providing research, writing and speaking services on a wide range of business and technology issues. Martin was previously a director at Bloor Research, and has worked with IT as a user and analyst for over 20 years. He is a long-term contributor to silicon.com through videoed debates and his weekly column, which tackles a wide range of issues. He can be contacted through his website.