Chapter 3

Personnel Management

Chapter 1 indicated that people are the primary determinant of

software quality and productivity. This chapter identifies numer-
ous practices for finding, nurturing, and retaining the best
people. It also defines a step-by-step procedure that incorpo-
rates these practices so that they can be easily followed.

An organization’s most important asset and primary determinant of success

is talented people [1–4]. Weigers, for example, has said [5]: “your team
members will always be your greatest asset. … hiring and nurturing
outstanding software engineers will give you a competitive edge no
process definition can best.” Several studies of software projects support
this hypothesis by showing that talented people solve the key problems
and produce the best products [3, 6–12]. In these studies, the best pro-
grammers were generally 15 to 30 times better than the worst ones in
terms of both productivity and quality factors [3, 11, 13–16]. Some of these
studies claimed that the differences are even greater. For example, Gibbs
said [17]:

“You can walk into a typical company and find two guys sharing
an office, getting the same salary and having essentially the
same credentials and yet find a factor of 100 difference in the
number of instructions per day that they produce.”

At least one study has shown even larger differences. The variability
of productivity of software personnel among more than 400 military

51
52
Software Engineering Quality Practices

software systems ranged from ten source lines of code per month to
several thousand [13]. Even more surprisingly, other experiments demon-
strated that some people simply cannot do the work. DeMarco and Lister
conducted an experiment in which 166 programmers were tasked to
complete the same assignment [8]. They found that the programmers
exhibited differences in productivity of about five to one on the same
small project. However, the most interesting result of the study was that
13 of the 166 programmers did not finish the project at all. In another
study with similar findings, Curtis presented a group of 60 professional
programmers with what he characterized as a simple debugging task [6].
Despite its simplicity, six of the professional programmers were not able
to complete the task. Hence, about 10 percent of software engineers either
required huge amounts of time to complete their work or others would
have to complete it for them, which translates into an actual loss of net
output per unit of cost.
Furthermore, the performance of these programmers had no significant
correlation with years of programming experience or scores on standard
programming aptitude tests. This indicates that general programming skill
dominates training and on-the-job experience, which later studies con-
firmed [12, 18]. In sum, the most important ingredient of a successful
project is to have talented people work on it [1, 19, 20]. Br ooks, for
example, said that good design practices can be taught; however, great
designs come from great designers [21] who produce structures that are
faster, smaller, simpler, cleaner, and produced with less effort [22]. Larman
supports this view when he said [23]: “More important than following an
official process or method is that a developer acquire skill in how to
create a good design, and that organizations foster this kind of skill
development. This comes from mastering a set of principles and heuristics
related to identifying and abstracting suitable objects and to assigning
responsibilities to them.” Unfortunately, McConnell believes that 95 percent
of software engineers lack fundamental design knowledge, enabling them
to produce good designs [9]. I personally believe this is a good approx-
imation of the truth, and even extends to the other aspects of the software
development process — requirements definition, coding, and testing. One
cause of this situation is that most practitioners do not maintain their
technical skills and knowledge. According to Humphrey [3], only 19
percent regularly read technical journals and only 8 percent attend pro-
fessional conferences.
The characteristics that one should expect from superior software
engineers are shown in Table 3.1 [2, 3]. To put the importance of these
characteristics in perspective, consider that the typical software engineer
needs one to two years to become comfortable with a methodology [20].
 Personnel Management
53

TABLE 3.1 Characteristics of

Superior Software Engineers
Committed Driven
Communicative Flexible
Competent Honest
Confident Industrious
Creative Intelligent
Dedicated Knowledgeable
Disciplined Motivated

This implies that if an organization uses average talent, it cannot evolve

at the rate of technological change. Thus, to keep abreast of technology,
an organization must hire people who have superior comprehension
capabilities [24], which allows them to use newly developed technologies.

3.1 Practices for Staffing an Organization

Few organizations know how to effectively hire talented people. This
section identifies a small number of key practices that help identify these
people.

Practice 3.1. Define minimal standards of knowledge for software per-

sonnel. Human performance of software personnel depends on a broad
base of relevant knowledge [7, 19]. Therefore, an organization should
define minimal levels of knowledge that enable people to effectively and
efficiently perform a variety of tasks. Brooks says, for example, that
programming knowledge, domain knowledge, and comprehension strat-
egies are essential to understand software [25]. I generally agree with this
assessment and believe that people should have a breadth of knowledge
in the following topics, which provides a foundation for intuitive judge-
ment, permitting people to grasp new issues and concepts much quicker
than those who do not have this knowledge [3].

Computer science knowledge. People should have a basic under-

standing of algorithms, data structures, programming languages, and com-
puter architecture. In addition, people should have used a variety of
programming languages and systems and become proficient in at least
one higher-level language. Furthermore, people should have deep knowl-
edge of at least two of the following areas: algorithms, data structures,
54
Software Engineering Quality Practices

computer networks, database systems, human–computer communication,

operating systems, and programming languages. Currently, the primary
function of colleges and universities is to teach students this material.
Unfortunately, only about 15 percent of the educational institutions in
America are accredited by the Computer Science Accreditation Board,
which indicates that an educational institution does a good job of teaching
this material, and few outside America are accredited by it [26].

Software engineering knowledge. People should have practical

knowledge about how to develop quality software and manage the risks
of developing it. This practical knowledge should include an understand-
ing of software process models and the software life cycle. People should
know how to write good requirements, design suitable software systems,
and produce reliable implementations. Most of this knowledge is learned
on the job, if learned at all. However, recently, a few institutions have
started to offer degrees specializing in software engineering.

Domain knowledge. To develop quality software for an application

domain requires that people working in that domain have a good under-
standing of it. It is impractical for this kind of knowledge to be taught at
an educational institution, so it is generally learned on the job. Hence,
work assignments should be designed, in part, to enhance this learning
[27]. In addition, an organization should provide other mechanisms for
capturing this knowledge and transferring it to others.
Note that these requirements differ substantially from what most orga-
nizations define in a job description. For example, most organizations
emphasize specific skills, such as knowledge of a specific database system
or programming language. Unfortunately, requiring this kind of specific
knowledge without requiring an understanding of the more general knowl-
edge will lead to a workforce that has difficulty perceiving the real
problems facing an organization or creating innovative solutions for them.
Instead, an organization should stress hiring people with fundamentals
that enable them to learn specific tools quickly [28].
Furthermore, an organization should quantify people’s knowledge
using the following seven stages of expertise [29]:

1. Innocent: an individual is unaware of the subject.

2. Aware: an individual has read an article about the subject.
3. Apprentice: an individual has attended a seminar on the subject
or read a book about it.
4. Practitioner: an individual is ready to use knowledge of the subject.
5. Journeyman: an individual who uses subject knowledge naturally
and automatically.
 Personnel Management
55

6. Master: an individual who has internalized subject knowledge and

knows when to break the rules.
7. Expert: an individual who writes articles or books and gives lectures
on the subject.

Practice 3.2. Use a defined process to evaluate a candidate’s knowledge.

This will reduce turnover and minimize overhead costs [30]. The formal
process should include the following sequence of activities.

Step 1. Interview each candidate. When interviewing a candidate,

have every person who might work with the candidate evaluate
him [2, 27, 28], possibly as a group to increase efficiency and
effectiveness [31], and inform every person who will interview a
candidate the reason for hiring another person [28].
During each interview, attempt to identify the problem-solving
skills of the candidate by asking situational questions [31] and
analyzing the candidate’s behavior. A good way to do this is to
ask the candidate how he would go about solving a simple problem
[28]. In addition, such a problem will help the interviewer evaluate
the candidate’s knowledge. A problem that I like to pose is one
where I ask the candidate to develop an online phone book. I
define a few brief requirements that do not uniquely define the
product. Then I evaluate the decisions that the candidate makes
to develop a product that satisfies my ambiguously stated needs.
Throughout this process, the candidate will either verbalize his
assumptions or ask me direct questions. When direct questions are
asked, I answer them. When assumptions are identified, I some-
times contradict them to see how the candidate proceeds. In sum,
there is no single correct answer to this open-ended problem, but
it provides a great way to evaluate what the candidate knows about
computer science and software engineering, as well as evaluating
his decision processes.
You should also ask several more questions during the interview
process [28, 31, 32]. To better understand the general work habits
of a candidate, consider asking the following questions:

How many assignments do you like to work on at one time?

When you have lots of assignments to complete and only a
very limited time to do them, what do you do?

Do you prefer work that is highly structured, somewhat struc-
tured, or unstructured?

Do you prefer working alone, with small groups, or in large
groups?
56
Software Engineering Quality Practices

What’s most important to you when you work with people?

How do you work best with people?

When working on a project, what do you do to make it a
success?

Have you encountered someone in the past who you thought
was inefficient or ineffective? If yes, what did you do about the
situation?

How do you deal with problem employees?

To better understand the goals, beliefs, and values of the candidate,

consider asking the following questions:

What are your goals? And, how do you plan to achieve them?

What matters most to you in your work? What part of it do you
find most satisfying? What activities do you least like to perform?

What most discourages you or frustrates you on your job? How
do you handle this frustration?

What skills, knowledge, and abilities do you need to develop
or improve?

Do you prefer to follow a defined process? If so, name one
that you like, or provide an example of how you like to perform
work.

To better understand how the candidate views himself and assesses

the work he does, consider asking the following questions:

What are your strongest skills and how were they developed?

Of all the projects you have worked on, which one do you
take the greatest pride in? Why? Similarly, which one do you
take the least pride in? Why?

What have been the most difficult problems that you encoun-
tered on a job? What did you do about them?

What is the biggest mistake you made on a job? What did you
learn from it?

To better understand how the candidate will satisfy the current

needs of the organization, consider asking the following questions:

Who determines the work you do? What role do you play in
the process?

What books or articles have you recently read? Summarize one
of those articles or books.

How have you managed or dealt with change in your organi-
zation?

What is your experience with a specific technology? How did
you learn how to use that specific technology? How does that