From: EBERARD@ADA20.ISI.EDU (Edward V. Berard)
Subject: The Human Element in Software Engineering
Date: Tue, 19-May-87 07:31:13 EDT [thread overview]
Date: Tue May 19 07:31:13 1987
Message-ID: <8705191313.AA06594@ucbvax.Berkeley.EDU> (raw)
There is a good deal of wisdom in Sam Harbaugh's response to my
recent four-part article on Ada Education and Training. I especially
agree with his citing of the old adage: "Never try to teach a pig to
sing: it will waste your time and it annoys the pig." In fact, another
old saying: "Neither cast ye your pearls before swine." (Matthew 7:6)
also came to mind regarding the natural human tendency to reject new
technology.
Technologists, in general, very often ignore the human element in
technology. Many erroneously believe that it is technology that
advances technology, when, in fact, it is economics, politics, and
sociology which are the main causes of technological change. Nowhere
is the attempt to remove human considerations from technology so
blatant as it is in the state-of-the-practice of software engineering.
Consider the following:
1) Although people such as Barry Boehm have been telling us for
years that the greatest improvements in technology will occur
when we improve the capabilities of the humans involved in the
process (See the front cover of Barry's book, "Software
Engineering Economics."), we continually ignore this advice. It
seems we much more comfortable creating new automated tools than
we are with measuring and improving the capabilities of the
humans who will be using the tools.
2) Sociologists tell us that while bringing a group of people one
generation ahead in technology is difficult, bringing a group of
people ahead two generations of technology is all but
impossible. In the area of software engineering, the
state-of-the-practice is easily two or more generations behind
the state-of-the-art. This leads to some interesting results.
For example, while we currently possess the technology to
increase our software engineering productivity by at least an
order of magnitude, we cannot expect people to begin using this
technology on a large scale for at least a decade. (Yes, Sam, I
do agree with your observation.)
3) New technology is seldom what people expect it to be. I used to
give a seminar on "Measuring and Improving Programmer
Productivity." This seminar was attended chiefly by managers who
expected me to tell them how to make their programmers code
faster in the programming language of their choice. When they
heard that the largest gains in productivity required such items
as a shift to fourth-generation languages, off-the-shelf
software, and smaller technical staffs, the managers often
refused to accept the facts, *even when presented with
documented evidence supporting the facts.*
4) Even when people claim that they are ready to accept new
technology, or even to enthusiastically pursue new types of
technology, they often spend enormous amounts of resources (in
most cases, the majority of their resources) "re-inventing or
re-discovering the wheel." The concept of a simple literature
search is beyond most of the people in the software business
today. Even those who are capable of even feeble scanning of the
technical literature are ill-equipped to understand, much less
accurately interpret, what they find. Recently, someone from one
of the more prestigious centers of software engineering
technology transfer called to ask me about a methodology. This
person was part of a group which was researching software
development methodologies. This person was shocked when I told
him that the work he was charged with had been done at least six
times before. Indeed, in addition to numerous government
sponsored reports available on the topic, five or six IEEE
tutorials, at least three hardback books, numerous foreign
government studies, and several publicly available industry and
academic studies, there is at least one public seminar on the
topic he was researching.
5) Technical people seem very uncomfortable with concepts of
ethics, morals, and responsibility. For example, few software
engineering courses discuss the ethical implications of a
managerial or technical decision. Although there are quite a
number of courses and seminars about software law, most deal
with the protection of copyrights -- as opposed to the legal
responsibilities of the author of the software if reasonable use
of the software results in damage to the user.
As I have stated before, most people are more comfortable talking
about technological change than doing anything about it. As a
consultant, I am often asked to pose solutions to any number of
software engineering problems. It is a sad fact that most of the
people who pose the problems to me are "insane." (Insane by W.S.
Humphrey's definition: "There is a definition of insanity that applies
to software development. It is said that insane persons believe they
can continue doing the same thing over and over and get different
results.") They do not want to hear the best, or even a correct,
answer. They want to hear more of the same.
Sam is also right on another point. The financial rewards of being on
the leading edge of technology are meager at best. It is little
comfort to realize two years later that you did indeed accurately
predict the technological future, but will have to wait another two
years to take economic advantage of your prediction. In Greek
mythology, a woman named Casandra was cursed by the gods. She was
given the power to accurately predict the future. However, the gods
made sure that no one would believe her predictions.
There is, however, another view. Without people motivating and
cajoling the technical population, there would be little work for
people like Sam. So, in the future, I will continue in my attempts to
"teach pigs to sing." I guess what motivates me is that I have had
some success with changing pigs into quasi-rational human beings.
(Another of the ancient Greeks, Homer, told us about Circe, a
sorceress who turned men into animals. You might say that I am
attempting to "reverse the curse.")
-- Ed Berard
(301) 695-6960
-------
reply other threads:[~1987-05-19 11:31 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox