The Human Element In Software Engineering

The Human Element In Software Engineering

Post by Edward Berar » Fri, 01 Aug 2003 01:41:53

--> This posting first appeard in comp.lang.ada on May 19, 1987.
--> Although taken slightly out of context, its message is still
--> relevant today.

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

   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

Edward V. Berard              | Voice: (901) 309-1912
The Object Agency, L.L.C.     | Fax: (901) 755-5622

Germantown, Tennessee 38138   | WWW:


The Human Element In Software Engineering

Post by JXSter » Fri, 01 Aug 2003 04:32:16

>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.")

Well, bless you.  Kiss a few frogs, while you're at it.

I went to a couple of job interviews this week, and just killing time
on the freeway coming back, I was comparing and contrasting the kinds
of questions I was asked to those that were asked in interviews twenty
years ago.  Night and day.  Back then, the standard interview was
about career path, today it's all about product features you have
used.  The only mention of the human element I see in recruitment ads
or interviews is concern with duration of employment or ability to
work in high-pressure, chaotic environments (two sides of the same
coin).  Never a mention of career opportunities.  Some employment
manuals probably still contain sections on balancing work and family,
but it seldome makes it into the hiring process, apparently.

Just some observations regrading the modern myth of the magical
machine, and our relationship to it.



1. Free check-ins or stable check-ins?

Hi all,

I'm hoping someone could give me insight to how they do things...(BTW, we
are using VSS 6.0 and
VisualStudio6.0 on an NT platform)

I was thinking about mandating stable check-ins for all code in our project.
That is, nobody checks in code unless it is deemed complete and workable.
Due to the way VSS <project> labels work (always labels latest versions of
all files), if code is checked in incomplete and a build is performed, it
could break the build. I've heard that if code is checked out for a long
period of time though (if a change takes a week or so), the code is more apt
to become corrupt. Is this true?
The alternative to this is to let developers check in code regardless of the
working state. If a build is performed, this may cause the build to break.
Also, if a "hotfix" needs to be performed, and if the code has already been
changed and is checked in incomplete, the hotfix will include the incomplete
code. If the code is stable, this is not a problem. If the code is still
checked out, at least the person responsible for the hotfix will know that
the code is being modified and can communicate with that person to get the
fix incorporated.

How do others here manage their source code with respect to the above?
Thanks for your thoughts!

2. A MediaOne Express and Me Tale [long]

3. CAN-MONTREAL: Software engineers for 3D human modeling

4. OE - Blocking unwanted mail

5. Engineers wanted: Software, Elec/Sys, Human Factors

6. Available: OpenVMS 6.0 Base Documentation Set

7. ATC Human Factors Engineer @ Sterling Software, Mt. View, CA

8. Question about Internet Naming Authorities

9. CFP: ICSE16 Software Engineering and Human-Computer Interaction Workshop

10. US/MELVILLE, NY/Human Factors/User Centered Design/Software/Sr. Usability Engineer

11. hardware engineers, software engineers and systems engineers