Police powers and individual liberty (1)

Given the state of public concern over civil liberties the writer is concerned with the law’s futile attempt at reconciling two contradictory aims – firstly, the need to catch criminals and, secondly, the desire to allow citizens to go about their business without interference by the police.

The law, ladies and gentlemen, has never satisfactorily come to terms with the problem. The law is often very confused and obscure on some of these ‘civil liberty’ issues but, frequently, it seems that the courts are prepared to ignore what certain rights the individual has if it will help the police in catching wrongdoers. So the citizen who proclaims, as he often does: “I know my rights” is probably unaware of just how limited those rights are.

Assisting the police:

The general rule is that no one is obliged to help the police with their inquiries. It may be one's social or even moral duty to do so but there is no law which says that one must; all the law requires is that one should not give false information to the police or waste police time. Anyone who does contravene this fundamental tenet is liable to a fine and/or imprisonment.

But of course most people do help the police; if everyone stood on their constitutional rights and refused to cooperate, the police's task would be impossible.

When the police stop someone in the street and ask him to 'come down to the station and help us with our inquiries', that request can be refused. The only way the police can make someone accompany them to the police station is to arrest him, and that can only be done in certain circumstances. As Lord Devlin eloquently quoted:

... "You may sometimes read in novels and detective stories ... that persons are sometimes taken into custody for questioning. There is no such power in this country. A man cannot be detained unless he is arrested".

Of course, Lord Devlin's remarks may be superseded by certain clauses within the Anti-Terrorist Bill where an individual may be held without charge. Nevertheless, this aside, few people know that this is the basis of the law and of course the police do not tell suspects of their right to refuse to go to 'the station'.

What then of a suspect's rights?

1. Police questioning -

If a person agrees to help the police, there are rules of conduct governing the manner in which he is to be questioned. These are laid down in the Judges' Rules and Home Office administrative directions which, in essence, gives guidelines to the police, but are not strictly binding on them. So, if a policeman conducts an interview that does not follow the terms of the Rules, it does not necessarily follow that the evidence obtained will be inadmissible - that is for the trial judge to decide. The judge will only probably rule it out if it would be oppressive or unfair to include it.

The law:

The police can question anyone but their questions need not be answered. As soon as there are grounds for suspecting that someone has committed an offence he must be cautioned that he not need say anything. Further, once he has been charged he must be given a second caution. Normally, the questions should then stop, but if for exceptional reasons he is asked more questions he should be told again that he not need answer.

Ladies and gentlemen, the writer has been involved within local advocacy and, through that work, is able to impart an accurate understanding of police and local authority powers. For example, many lawyers with large criminal practices say that the police often ignore the Judges' Rules. Certainly, there is some evidence that the Rules are not always followed. If the police should conduct their questioning in an improper manner, it is usually almost impossible for the suspect to prove afterwards that the Rules were broken. And, of course, even if he can prove that the Rules were not followed, the judge who hears his case may still allow the evidence against him to be heard.

The classic statement on the status of the Judges' Rules was made in 1918 but remains equally valid today:

The statement reads ...

... "These rules have not the force of law. They are administrative directions, the observance of which the police authorities should enforce on their subordinates as tending to the fair administration of justice. It is important that they do so, for statements obtained from prisoners contrary to the spirit of these Rules may be rejected as evidence by the judge presiding at the trial" (sic).

In general, of course, the police do follow the Rules, but it is difficult to see what justification there can be for having a set of Rules if they are not to be legally binding on the police.

The Rules set out under Home Office directions and, when a suspect may be interrogated, are namely:

1. The police can question a person about an offence whether or not he is in custody, unless he has been charged or told that he may be prosecuted for the offence. But, as stated above, the person can refuse to answer the questions;

2. As soon as there is evidence that gives reasonable grounds for suspecting that the person has committed an offence, he must be cautioned … “You are not obliged to say anything unless you wish to but what you say may be put into writing and given in evidence” and, thereafter, a record must be kept of the questioning and any statements made.

3. The questioning can continue until the suspect is charged, or told that he may be prosecuted. But then, he must be cautioned again: “Do you wish to say anything? You are not obliged to say anything unless you wish to do so, but whatever you say will be taken down in writing and may be given in evidence” and, normally, he should not be asked any more questions.

Exceptionally, additional questions are allowed: for instance, to clear up ambiguities or to prevent harm to the public. In the words of the Home Office circular, “Where they are necessary for the purpose of preventing or minimising harm or loss to some other person or to the public or for clearing up an ambiguity in a previous statement or answer”. If so, the accused should be cautioned for a third time – “I wish to put some questions to you about the offence … You are not obliged to answer any of these questions, but if you do the question and answer will be taken down in writing and may be given in evidence”.


... what of the problem of being verballed? Most lawyers and policemen would agree that the verbals problem has got out of hand. Is there a way through this mire?

The vexed question of verbals can arise after statements have been given to the police. This is the word used to describe admissions, or incriminating statements, that the police falsely allege to have been made by the accused.

When the police question, arrest, or charge a person, they keep a written record of the events and conversations. For example, the notebook might read: 'When charged, the accused said, "Fair enough, I did it"', but the accused may later deny ever having said those words. Either he is lying, or he has been 'verballed' by the police.

It is now normal for a considerable amount of time at criminal trials to be taken up with arguments as to what the accused did or did not say; in effect, there is a mini-trial within the trial, with the police officer being accused of giving false evidence.

Certainly, it does appear over recent years that this problem has got out of hand. Not only is it unfair on the police (and the accused) but it wastes a considerable amount of valuable court time, and often confuses the minds of the jurors.

The simplest solution would probably be to issue the police with pocket tape recorders so that there would be a full record of what was said, although even this would not be a complete safeguard against the mischievous suspect who shouts out, 'Stop hitting me!' The only complete answer would be to insist that all police questioning takes place in front of a sheriff or other court official.

Until better reforms are introduced, the best a suspect can do is to make his own written record of what is said, so he at least has some evidence to contradict the policeman's notebooks should he be verballed.

The existing environment –

One of the least thought-about factors in the systems development process is often the existing production environment. In other words, some relatively easy questions are commonly left aside, such as:

• What computers do we have?

• What software do we have?

• What PRODUCTION MIX do we have?

In this article, continuing on the theme of systems development, the author will address the first two questions in brief terms. The third is usually forgotten, that causes an array of problems within organisations.

Like it or not, our system will be required to function in an already existing environment, with all the attendant problems, handicaps and pitfalls. Not to recognise this point amounts to dismissing the constant plethora of issues associated with the technical environment. No doubt, anyone of us would like our system to be born in the best possible environment. For example, we would expect full telecommunications availability.

Human factors are, again, particularly relevant since problems may arise between two computer groups. In fact, we may be tempted to tell other people what they should have done. However, we must accept that we do not:

1. know everything about the current environment;

2. know what constraints may have existed before;

3. have the power to make things change immediately.

Consequently, when complaints are aired we are likely to be directed elsewhere. People may just listen, or we may be told that when our system reaches implementation, the whole environment will have changed. In fact, we should assume that the environment will not change - in any way that will facilitate system implementation.

We should always remember, ladies and gentlemen, that the existing environment includes people and systems. Whatever design we have reached, we must take account of the existing resources, because they will become crucial to the successful operation of the system in the future. If people are only accustomed to, for example, reading totals at the day-end, we had better provide a facility that will similarly organise the system to this end or else be prepared to retrain the people concerned adequately enough, or the system simply will not work.

Maintenance -

The topic of maintenance is often less than appealing to systems developers. We usually look at maintenance as something you have to do, not as something you would like to do. However, once the system is implemented, a maintenance team invariably will be required to update it. Not that I particularly support the idea of having a maintenance representative in the project. In fact, I have never personally used that approach and probably never will. Nevertheless, the company's maintenance needs will have to be considered in the design, coding and documentation of the system. Thorough knowledge on the part of the maintenance team will be necessary, so that the consequences of poor documentation can be understood.

It is important to appreciate the fact that the more we ignore maintenance, the more likely we are to become the maintainers of our own system. Nobody else will really be in a position to undertake major or minor systems surgery.

This problem has in the past been tackled through techniques such as structured programming and systems documentation. However, the best approach is to ensure that the coding and documentation can be understood by people outside the development team, so that they may be able to modify the system where necessary, at some future stage. Empirically, many of us have looked hard at our own programs to work out what we originally intended. So how can we expect someone to understand what we have done if we ourselves have problems and issues deciphering our own work?

This issue has been addressed in many different ways, but I personally feel the worst of all is what is called structured programming. The aim has been to state a series of rules such that anybody reading a program will understand what the code says. However, let us think about this. Programs, historically, were written in assembler. Then somebody invented something that would accept plain, English words, and convert them into machine language. Subsequent developments yielded high-level languages such as FORTRAN and COBOL. Typically, when we look back and read programming lessons of those days, we find that such languages were expected to be easy to code and read. Does such a consideration bear directly on the maintenance problem, whether then or in the future?

No matter how extensive our documentation, no matter how structured our programs, we will still have maintenance problems. We must also ask ourselves if we are building a system that can actually be maintained. The question then becomes: what is a maintainable system?

In my most recent project - and currently ongoing - a decision was reached in automating a system from excel spreadsheets that will, in due course, be fully automated. The cost implications of this decision, given the position of the company, is, in my opinion, a correct one. It avoids the difficulties of being concerned with bottlenecks that commonly arise with off-the-shelf packages and, most people competent with excel, will at least be able to systematically flow-chart the links. In this instance, documenting the procedural processes of maintenance will be minimal because excel works from a standard set of Microsoft procedures whatever the standard or capability of future users. A terms of reference will always exist either from reference material or from help-topics within the computer itself. In addition, running a company' accounting system under such a format can produce management accounts that are as good as any produced by advanced accounting packages. The principles of how accounts are formulated and produced is, of course, the overarching objective and not how complicated or costly a bought-in system will cost. To many small type organisations have been entrapped to the flavours of sales rhetoric when considering how they should proceed. As a senior management accountant once told me: "The best systems are derived from knowing the business and environment one is in and knowing how to build around those parameters". I endorse those sentiments, to this day.

In the next phase of my writing on 'systems development' the author intends to look specifically at the user and, in trying to understand him. This work will begin with a new post and, during the course of such deliberations, the writer intends to introduce further case studies drawn from personal experiences.