While clearing out my file cabinet, I uncovered the following, which struck me
as relevant to a lot of what goes on in comp.risks. Quoted from a paper, 'The
Emperor's Old Clothes', by Charles Antony Richard Hoare, published in CACM Feb
1981:
...there are two ways of constructing a software design: One way
is to make it so simple that there are _obviously_ no deficiencies
and the other way is to make it so complicated that there are no
_obvious_ deficiencies.
The first method is far more difficult. It demands the same skill,
devotion, insight, and even inspiration as the discovery of the
simple physical laws which underlie the complex phenomena of
nature. It also requires a willingness to accept objectives which
are limited by physical, logical, and technological constraints,
and to accept a compromise when conflicting objectives cannot be
met. No committee will ever do this until it is too late.
(The paper was the 1980 ACM Turing Award Lecture. The _'s represent his
italics.)
Related:
There are two ways of constructing a software desig One
way is to make it so simple that there are obviously no
deficiencies, and the other way is to make it so complicated
that there are no obvious deficiencies....
There are two ways of constructing a software design. One way is to make
it so simple that there are obviously no deficiencies and the other is to
make it so complicated that there are no obvious deficiencies....
There are two ways of constructing a software desig One way is to
make is so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies....
There are two ways of constructing a software desig One way is to
make is so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies....
brute force adj.
Describes a primitive programming style
one in which the programmer relies on the computer's processing
power instead of using his or her own intelligence to simplify the
problem, often ignoring problems of scale and applying naive
methods suited to small problems directly to large ones....
