Managing Information Technology
| Date | 01 March 1989 |
| DOI | https://doi.org/10.1108/eb027031 |
| Pages | 131-133 |
| Published date | 01 March 1989 |
| Author | Ralph Cornes |
| Subject Matter | Information & knowledge management |
Managing Information Technology
Ralph Cornes
I want to talk about information retrieval and why applications that are
developed to meet apparently simple requests often turn out to be less than
satisfactory.
Some years ago I attended a convention and found my neighbours were a
brace of
physicists.
We chatted about current projects and they dismissed my
payroll with the immortal phrase "ah yes, hours time rate equals pay", before
explaining the mindbending complexity of their programs for calculating fuel
loads to put rockets into orbit. I had to tell them that similar problems were set
for students at Cambridge in Regency England and all they had to do was to
translate gunpowder to liquid oxygen and they would be home and dry. No
doubt I had as firm a grasp of their problems as they had of mine.
My chief concern was making sure that the files for weekly payroll and
monthly salaries stayed in step with the files used for personnel management.
This necessitated analysing why they tended eventually to contradict each
other, and the designing of programs and procedures to remove the causes of
error. My aquaintances made the mistake that everyone in computing
continues to make.
They applied knowledge of computers which they knew inside-out to
applications of which they had only a superficial knowledge, and arrived at a
feasible answer which satisfied a tiny percentage of application requirements.
They could be excused because even data processing (DP) professionals were
making and continue to make the same kind of mistake.
DP professionals knew about payrolls and personnel records but didn't
appreciate the links because the computer highlighted the connections for the
first
time.
If they had thought about the work in both departments the
connections would have been obvious. Both process information about
employees, so a major problem is to establish that the information is not
contradictory.
A few years later DP realised this and decided that it was in the business of
building models of the real world. Everything in the real world is called an
entity which possesses characteristics or attributes. Essential stages of
application development became defining entities and their relationships, and
deciding the attributes which had to be coded into entity records.
DP continues to make the same kind of mistake, because having established
that he has to build a model of the real world, the DP professional builds a
model which gives correct but superficial answers before heaving a sigh of relief
and getting back to the real business of deciding how computer techniques can
be utilised in the application. So validation is fixed by reference to the integrity
rules of the database rather than to the kinds of errors that users make. Screens
are designed to minimise the cost of programming rather than to match manual
procedures. Reporting features are provided because they are there, rather than
131
To continue reading
Request your trial