14 Decision making Introduction
0
Subjects’ estimate of their ability
Proportion correct
0.5
0.6
0.7
0.8
0.9
1.0
0.6 0.7 0.8 0.9 1.0
∆
∆
∆
∆ ∆
∆
Easy Hard
Figure 0.18:
Subjects’ estimate of their ability (bottom scale) to correctly answer a question and actual performance in answering
on the left scale. The responses of a person with perfect self-knowledge is given by the solid line. Adapted from Lichtenstein.
[868]
true or false), which they had to answer. They then had to rate their confidence that they had answered the
question correctly. This process was repeated for a second statement, which differed from the first in having
the opposite true/false status.
The results showed that the more physics or music courses a subject had taken, the more confident they
were about their own abilities. However, a subject’s greater confidence in being able to correctly answer
a question, before seeing it, was not matched by a greater ability to provide the correct answer. In fact as
subjects’ confidence increased, the accuracy of the calibration of their own ability went down. Once they had
seen the question, and answered it, subjects were able to accurately calibrate their performance.
Subjects did not learn from their previous performances (in answering questions). They could have used
information on the discrepancy between their confidence levels before/after seeing previous questions to
improve the accuracy of their confidence estimates on subsequent questions.
The conclusion drawn by Glenberg and Epstein was that subjects’ overconfidence judgments were based
on self-classification as an expert, within a domain, not the degree to which they comprehended the text.
A study by Lichtenstein and Fishhoff
[868]
discovered a different kind of overconfidence effect. As the
difficulty of a task increased, the accuracy of people’s estimates of their own ability to perform the task
decreased. In this study subjects were asked general knowledge questions, with the questions divided into two
groups, hard and easy. The results in Figure 0.18 show that subjects’ overestimated their ability (bottom scale)
to correctly answer (actual performance, left scale) hard questions. On the other hand, they underestimated
their ability to answer easy questions. The responses of a person with perfect self-knowledge are given by
the solid line.
These, and subsequent results, show that the skills and knowledge that constitute competence in a particular
domain are the same skills needed to evaluate one’s (and other people’s) competence in that domain. People
who do not have these skills and knowledge lack metacognition (the name given by cognitive psychologists
to the ability of a person to accurately judge how well they are performing). In other words, the knowledge
that underlies the ability to produce correct judgment is the same knowledge that underlies the ability to
recognize correct judgment.
Some very worrying results, about what overconfident people will do, were obtained in a study performed
by Arkes, Dawes, and Christensen.
[52]
This study found that subjects used a formula that calculated the best
decision in a probabilistic context (provided to them as part of the experiment) less when incentives were
provided or the subjects thought they had domain expertise. This behavior even continued when the subjects
were given feedback on the accuracy of their own decisions. The explanation, given by Arkes et al., was that
when incentives were provided, people changed decision-making strategies in an attempt to beat the odds.
Langer
[820]
calls this behavior the illusion of control.
Developers overconfidence and their aversion to explicit errors can sometimes be seen in the handling
June 24, 2009 v 1.2 91
Introduction 14 Decision making
0
of floating-point calculations. A significant amount of mathematical work has been devoted to discovering
the bounds on the errors for various numerical algorithms. Sometimes it has been proved that the error
in the result of a particular algorithm is the minimum error attainable (there is no algorithm whose result
has less error). This does not seem to prevent some developers from believing that they can design a more
accurate algorithm. Phrases, such as mean error and average error, in the presentation of an algorithm’s
error analysis do not help. An overconfident developer could take this as a hint that it is possible to do better
for the conditions that prevail in his (or her) application (and not having an error analysis does not disprove it
is not better).
14.4 The impact of guideline recommendations on decision making
A set of guidelines can be more than a list of recommendations that provide a precomputed decision matrix.
A guidelines document can provide background information. Before making any recommendations, the
author(s) of a guidelines document need to consider the construct in detail. A good set of guidelines will
document these considerations. This documentation provides a knowledge base of the alternatives that might
be considered, and a list of the attributes that need to be taken into account. Ideally, precomputed values
and weights for each attribute would also be provided. At the time of this writing your author only has a
vague idea about how these values and weights might be computed, and does not have the raw data needed to
compute them.
A set of guideline recommendations can act as a lightening rod for decisions that contain an emotional
dimension. Adhering to coding guidelines being the justification for the decision that needs to be made.
justifying
decisions
0
Having to justify decisions can affect the decision-making strategy used. If developers are expected to adhere
to a set of guidelines, the decisions they make could vary depending on whether the code they write is
independently checked (during code review, or with a static analysis tool).
14.5 Management’s impact on developers’ decision making
Although lip service is generally paid to the idea that coding guidelines are beneficial, all developers seem to
have heard of a case where having to follow guidelines has been counterproductive. In practice, when first
introduced, guidelines are often judged by both the amount of additional work they create for developers
and the number of faults they immediately help locate. While an automated tool may uncover faults in
existing code, this is not the primary intended purpose of using these coding guidelines. The cost of adhering
to guidelines in the present is paid by developers; the benefit is reaped in the future by the owners of the
software. Unless management successfully deals with this cost/benefit situation, developers could decide it is
not worth their while to adhere to guideline recommendations.
What factors, controlled by management, have an effect on developers’ decision making? The following
subsections discuss some of them.
14.5.1 Effects of incentives
Some deadlines are sufficiently important that developers are offered incentives to meet them. Studies, on
use of incentives, show that their effect seems to be to make people work harder, not necessarily smarter.
Increased effort is thought to lead to improved results. Research by Paese and Sniezek
[1060]
found that
increased effort led to increased confidence in the result, but without there being any associated increase in
decision accuracy.
Before incentives can lead to a change of decision-making strategies, several conditions need to be met:
•
The developer must believe that a more accurate strategy is required. Feedback on the accuracy
of decisions is the first step in highlighting the need for a different strategy,
[592]
but it need not be
sufficient to cause a change of strategy.
•
A better strategy must be available. The information needed to be able to use alternative strategies may
not be available (for instance, a list of attribute values and weights for a weighted average strategy).
• The developer must believe that they are capable of performing the strategy.
92 v 1.2 June 24, 2009
14 Decision making Introduction
0
14.5.2 Effects of time pressure
Research by Payne, Bettman, and Johnson,
[1084]
and others, has shown that there is a hierarchy of responses
for how people deal with time pressure:
1. They work faster.
2. If that fails, they may focus on a subset of the issues.
3. If that fails, they may change strategies (e.g., from alternative based to attribute based).
If the time pressure is on delivering a finished program, and testing has uncovered a fault that requires
changes to the code, then the weighting assigned to attributes is likely to be different than during initial
development. For instance, the risk of a particular code change impacting other parts of the program is
likely to be a highly weighted attribute, while maintainability issues are usually given a lower weighting as
deadlines approach.
14.5.3 Effects of decision importance
Studies investigating at how people select decision-making strategies have found that increasing the benefit
for making a correct decision, or having to make a decision that is irreversible, influences how rigorously a
strategy is applied, not which strategy is applied.
[104]
The same coding construct can have a different perceived importance in different contexts. For instance,
defining an object at file scope is often considered to be a more important decision than defining one in block
scope. The file scope declaration has more future consequences than the one in block scope.
An irreversible decision might be one that selects the parameter ordering in the declaration of a library
function. Once other developers have included calls to this function in their code, it can be almost impossible
(high cost/low benefit) to change the parameter ordering.
14.5.4 Effects of training
A developer’s training in software development is often done using examples. Sample programs are used
to demonstrate the solutions to small problems. As well as learning how different constructs behave, and
how they can be joined together to create programs, developers also learn what attributes are considered to
be important in source code. They learn the implicit information that is not written down in the text books.
Sources of implicit learning include the following:
•
The translator used for writing class exercises. All translators have their idiosyncrasies and beginners
are not sophisticated enough to distinguish these from truly generic behavior. A developer’s first
translator usually colors his view of writing code for several years.
•
Personal experiences during the first few months of training. There are usually several different
alternatives for performing some operation. A bad experience (perhaps being unable to get a program
that used a block scope array to work, but when the array was moved to file scope the program worked)
with some construct can lead to a belief that use of that construct was problem-prone and to be avoided
(all array objects being declared, by that developer, at file scope and never in block scope).
•
Instructor biases. The person teaching a class and marking submitted solutions will impart their own
views on what attributes are important. Efficiency of execution is an attribute that is often considered
to be important. Its actual importance, in most cases, has declined from being crucial 50 years ago
to being almost a nonissue today. There is also the technical interest factor in trying to write code
as efficiently as possible. A related attribute is program size. Praise is more often given for short
programs, rather than longer ones. There are applications where the size of the code is important,
but generally time spent writing the shortest program is wasted (and may even be more difficult to
comprehend than a longer program).
•
Consideration for other developers. Developers are rarely given practical training on how to read code,
or how to write code that can easily be read by others. Developers generally believe that any difficulty
others experience in comprehending their code is not caused by how they wrote it.
June 24, 2009 v 1.2 93
Introduction 14 Decision making
0
•
Preexisting behavior. Developers bring their existing beliefs and modes of working to writing C source.
These can range from behavior that is not software-specific, such as the inability to ignore sunk costs
(i.e., wanting to modify an existing piece of code, they wrote earlier, rather than throw it away and
starting again; although this does not seem to apply to throwing away code written by other people), to
the use of the idioms of another language when writing in C.
•
Technically based. Most existing education and training in software development tends to be based
on purely technical issues. Economic issues are not usually raised formally, although informally
time-to-completion is recognized as an important issue.
Unfortunately, once most developers have learned an initial set of attribute values and weightings for source
code constructs, there is usually a period of several years before any subsequent major tuning or relearning
takes place. Developers tend to be too busy applying their knowledge to question many of the underlying
assumptions they have picked up along the way.
Based on this background, it is to be expected that many developers will harbor a few myths about what
constitutes a good coding decision in certain circumstances. These coding guidelines cannot address all
coding myths. Where appropriate, coding myths commonly encountered by your author are discussed.
14.5.5 Having to justify decisions
Studies have found that having to justify a decision can affect the choice of decision-making strategy to be
justifying deci-
sions
used. For instance, Tetlock and Boettger
[1368]
found that subjects who were accountable for their decisions
used a much wider range of information in making judgments. While taking more information into account
did not necessarily result in better decisions, it did mean that additional information that was both irrelevant
and relevant to the decision was taken into account.
It has been proposed, by Tversky,
[1405]
that the elimination-by-aspects heuristic is easy to justify. However,
while use of this heuristic may make for easier justification, it need not make for more accurate decisions.
A study performed by Simonson
[1267]
showed that subjects who had difficulty determining which alter-
native had the greatest utility tended to select the alternative that supported the best overall reasons (for
choosing it).
Tetlock
[1367]
included an accountability factor into decision-making theory. One strategy that handles
accountability as well as minimizing cognitive effort is to select the alternative that the perspective audience
(i.e., code review members) is thought most likely to select. Not knowing which alternative they are likely to
select can lead to a more flexible approach to strategies. The exception occurs when a person has already
made the decision; in this case the cognitive effort goes into defending that decision.
During a code review, a developer may have to justify why a particular decision was made. While
developers know that time limits will make it very unlikely that they will have to justify every decision, they
do not know in advance which decisions will have to be justified. In effect, the developer will feel the need to
be able to justify most decisions.
Requiring developers to justify why they have not followed a particular guideline recommendation can
be a two-edged sword. Developers can respond by deciding to blindly follow guidelines (the path of least
resistance), or they can invest effort in evaluating, and documenting, the different alternatives (not necessarily
a good thing since the invested effort may not be warranted by the expected benefits). The extent to which
some people will blindly obey authority was chillingly demonstrated in a number of studies by Milgram.
[949]
14.6 Another theory about decision making
The theory that selection of a decision-making strategy is based on trading off cognitive effort and accuracy
is not the only theory that has been proposed. Hammond, Hamm, Grassia, and Pearson
[548]
proposed that
analytic decision making is only one end of a continuum; at the other end is intuition. They performed a
study, using highway engineers, involving three tasks. Each task was designed to have specific characteristics
(see Table 0.12). One task contained intuition-inducing characteristics, one analysis-inducing, and the third
an equal mixture of the two. For the problems studied, intuitive cognition outperformed analytical cognition
in terms of the empirical accuracy of the judgments.
94 v 1.2 June 24, 2009
15 Expertise Introduction
0
Table 0.12: Inducement of intuitive cognition and analytic cognition, by task conditions. Adapted from Hammond.
[548]
Task Characteristic
Intuition-Inducing State of
Task Characteristic
Analysis-Inducing State of Task
Characteristic
Number of cues Large (>5) Small
Measurement of cues Perceptual measurement Objective reliable measurement
Distribution of cue values
Continuous highly variable
distribution
Unknown distribution; cues are
dichotomous; values are discrete
Redundancy among cues High redundancy Low redundancy
Decomposition of task Low High
Degree of certainty in task Low certainty High certainty
Relation between cues and criterion Linear Nonlinear
Weighting of cues in environmental model Equal Unequal
Availability of organizing principle Unavailable Available
Display of cues Simultaneous display Sequential display
Time period Brief Long
One of the conclusions that Hammond et al. drew from these results is that “Experts should increase their
awareness of the correspondence between task and cognition”. A task having intuition-inducing characteris-
tics is most likely to be out carried using intuition, and similarly for analysis-inducing characteristics.
Many developers sometimes talk of writing code intuitively. Discussion of intuition and flow of conscious-
ness are often intermixed. The extent to which either intuitive or analytic decision making (if that is how
0 developer
flow
developers operate) is more cost effective, or practical, is beyond this author’s ability to even start to answer.
It is mentioned in this book because there is a bona fide theory that uses these concepts and developers
sometimes also refer to them.
Intuition can be said to be characterized by rapid data processing, low cognitive control (the consistency
developer
intuition
with which a judgment policy is applied), and low awareness of processing. Its opposite, analysis, is
characterized by slow data processing, high cognitive control, and high awareness of processing.
15 Expertise
People are referred to as being experts, in a particular domain, for several reasons, including: expertise
•
Well-established figures, perhaps holding a senior position with an organization heavily involved in
that domain.
• Better at performing a task than the average person on the street.
• Better at performing a task than most other people who can also perform that task.
•
Self-proclaimed experts, who are willing to accept money from clients who are not willing to take
responsibility for proposing what needs to be done.
[669]
Schneider
[1225]
defines a high-performance skill as one for which (1) more than 100 hours of training are
required, (2) substantial numbers of individuals fail to develop proficiency, and (3) the performance of an
expert is qualitatively different from that of the novice.
In this section, we are interested in why some people (the experts) are able to give a task performance that
is measurably better than a non-expert (who can also perform the task).
There are domains in which those acknowledged as experts do not perform significantly better than those
considered to be non-experts.
[194]
For instance, in typical cases the performance of medical experts was not
much greater than those of doctors after their first year of residency, although much larger differences were
seen for difficult cases. Are there domains where it is intrinsically not possible to become significantly better
than one’s peers, or are there other factors that can create a large performance difference between expert
and non-expert performances? One way to help answer this question is to look at domains where the gap
between expert and non-expert performance can be very large.
June 24, 2009 v 1.2 95
Introduction 15 Expertise
0
It is a commonly held belief that experts have some innate ability or capacity that enables them to do what
they do so well. Research over the last two decades has shown that while innate ability can be a factor in
performance (there do appear to be genetic factors associated with some athletic performances), the main
factor in acquiring expert performance is time spent in deliberate practice.
[401]
Deliberate practice is different from simply performing the task. It requires that people monitor their
practice with full concentration and obtain feedback
[592]
on what they are doing (often from a professional
teacher). It may also involve studying components of the skill in isolation, attempting to improve on particular
aspects. The goal of this practice being to improve performance, not to produce a finished product.
Studies of the backgrounds of recognized experts, in many fields, found that the elapsed time between
them starting out and carrying out their best work was at least 10 years, often with several hours of deliberate
practice every day of the year. For instance, Ericsson, Krampe, and Tesch-Romer
[402]
found that, in a study
of violinists (a perceptual-motor task), by age 20 those at the top level had practiced for 10,000 hours, those
at the next level down 7,500 hours, and those at the lowest level of expertise had practiced for 5,000 hours.
They also found similar quantities of practice being needed to attain expert performance levels in purely
mental activities (e.g., chess).
People often learn a skill for some purpose (e.g., chess as a social activity, programming to get a job)
without the aim of achieving expert performance. Once a certain level of proficiency is achieved, they stop
trying to learn and concentrate on using what they have learned (in work, and sport, a distinction is made
between training for and performing the activity). During everyday work, the goal is to produce a product or
to provide a service. In these situations people need to use well-established methods, not try new (potentially
dead-end, or leading to failure) ideas to be certain of success. Time spent on this kind of practice does not
lead to any significant improvement in expertise, although people may become very fluent in performing
their particular subset of skills.
What of individual aptitudes? In the cases studied by researchers, the effects of aptitude, if there are any,
have been found to be completely overshadowed by differences in experience and deliberate practice times.
What makes a person willing to spend many hours, every day, studying to achieve expert performance is open
to debate. Does an initial aptitude or interest in a subject lead to praise from others (the path to musical and
chess expert performance often starts in childhood), which creates the atmosphere for learning, or are other
issues involved? IQ does correlate to performance during and immediately after training, but the correlation
reduces over the years. The IQ of experts has been found to be higher than the average population at about
the level of college students.
In many fields expertise is acquired by memorizing a huge amount of, domain-specific, knowledge and
having the ability to solve problems using pattern-based retrieval on this knowledge base. The knowledge is
structured in a form suitable for the kind of information retrieval needed for problems in a domain.
[403]
A study by Carlson, Khoo, Yaure, and Schneider
[201]
examined changes in problem-solving activity as
subjects acquired a skill (trouble shooting problems with a digital circuit). Subjects started knowing nothing,
were given training in the task, and then given 347 problems to solve (in 28 individual, two-hour sessions,
over a 15-week period). The results showed that subjects made rapid improvements in some areas (and little
thereafter), extended practice produced continuing improvement in some of the task components, subjects
acquired the ability to perform some secondary tasks in parallel, and transfer of skills to new digital circuits
was substantial but less than perfect. Even after 56 hours of practice, the performance of subjects continued
to show improvements and had not started to level off. Where are the limits to continued improvements? A
study by Crossman
[303]
of workers producing cigars showed performance improving according to the power
law of practice for the first five years of employment. Thereafter performance improvements slow; factors
power law
of learning
0
cited for this slow down include approaching the speed limit of the equipment being used and the capability
of the musculature of the workers.
15.1 Knowledge
A distinction is often made between different kinds of knowledge. Declarative knowledge are the facts;
developer
knowledge
procedural knowledge are the skills (the ability to perform learned actions). Implicit memory is defined as
96 v 1.2 June 24, 2009
15 Expertise Introduction
0
memory without conscious awareness— it might be considered a kind of knowledge.
0 implicit learn-
ing
15.1.1 Declarative knowledge
This consists of knowledge about facts and events. For instance, the keywords used to denote the integer types
declarative
knowledge
are
char
,
short
,
int
, and
long
. This kind of knowledge is usually explicit (we know what we know), but
there are situations where it can be implicit (we make use of knowledge that we are not aware of having
[862]
).
The coding guideline recommendations in this book have the form of declarative knowledge.
It is the connections and relationships between the individual facts, for instance the relative sizes of
the integer types, that differentiate experts from novices (who might know the same facts). This kind of
knowledge is rather like web pages on the Internet; the links between different pages corresponding to the
connections between facts made by experts. Learning a subject is more about organizing information and
creating connections between different items than it is about remembering information in a rote-like fashion.
This was demonstrated in a study by McKeithen, Reitman, Ruster, and Hirtle,
[931]
who showed that
developers with greater experience with a language organized their knowledge of language keywords in a
more structured fashion. Education can provide the list of facts, it is experience that provides the connections
between them.
The term knowledge base is sometimes used to describe a collection of information and links about a
given topic. The C Standard document is a knowledge base. Your author has a C knowledge base in his head,
as do you the reader. This book is another knowledge base dealing with C. The difference between this book
and the C Standard document is that it contains significantly more explicit links connecting items, and it also
contains information on how the language is commonly implemented and used.
15.1.2 Procedural knowledge
This consists of knowledge about how to perform a task; it is often implicit. procedural
knowledge
Knowledge can start off by being purely declarative and, through extensive practice, becomes procedural;
for instance, the process of learning to drive a car. An experiment by Sweller, Mawer, and Ward
[1353]
showed
how subjects’ behavior during mathematical problem solving changed as they became more proficient. This
suggested that some aspects of what they were doing had been proceduralized.
Some of the aspects of writing source code that can become proceduralized are discussed elsewhere.
0 developer
flow
0 automatiza-
tion
15.2 Education
What effect does education have on people who go on to become software developers? developer
education
Page 206 of Hol-
land et al.
[595]
Education should not be thought of as replacing the rules that people use for understanding the world but rather
as introducing new rules that enter into competition with the old ones. People reliably distort the new rules in
the direction of the old ones, or ignore them altogether except in the highly specific domains in which they were
taught.
Education can be thought of as trying to do two things (of interest to us here)— teach students skills
(procedural knowledge) and providing them with information, considered important in the relevant field,
to memorize (declarative knowledge). To what extent does education in subjects not related to software
development affect a developer’s ability to write software?
Some subjects that are taught to students are claimed to teach general reasoning skills; for instance,
philosophy and logic. There are also subjects that require students to use specific reasoning skills, for
instance statistics requires students to think probabilistically. Does attending courses on these subjects
actually have any measurable effect on students’ capabilities, other than being able to answer questions
in an exam. That is, having acquired some skill in using a particular system of reasoning, do students
apply it outside of the domain in which they learnt it? Existing studies have supplied a No answer to this
question.
[936,1028]
This No was even found to apply to specific skills; for instance, statistics (unless the
problem explicitly involves statistical thinking within the applicable domain) and logic.
[226]
A study by Lehman, Lempert, and Nisbett
[844]
measured changes in students’ statistical, methodological,
and conditional reasoning abilities (about everyday-life events) between their first and third years. They
June 24, 2009 v 1.2 97
Introduction 15 Expertise
0
found that both psychology and medical training produced large effects on statistical and methodological
reasoning, while psychology, medical, and law training produced effects on the ability to perform conditional
reasoning. Training in chemistry had no affect on the types of reasoning studied. An examination of the skills
taught to students studying in these fields showed that they correlated with improvements in the specific
types of reasoning abilities measured. The extent to which these reasoning skills transferred to situations
that were not everyday-life events was not measured. Many studies have found that in general people do not
expertise
transfer to an-
other domain
0
transfer what they have learned from one domain to another.
It might be said that passing through the various stages of the education process is more like a filter than a
learning exercise. Those that already have the abilities being the ones that succeed.
[1434]
A well-argued call
to arms to improve students’ general reasoning skills, through education, is provided by van Gelder.
[1433]
Good education aims to provide students with an overview of a subject, listing the principles and major
issues involved; there may be specific cases covered by way of examples. Software development does require
knowledge of general principles, but most of the work involves a lot of specific details: specific to the
application, the language used, and any existing source code, while developers may have been introduced to
the C language as part of their education. The amount of exposure is unlikely to have been sufficient for the
building of any significant knowledge base about the language.
15.2.1 Learned skills
Education provides students with learned knowledge, which relates to the title of this subsection learned
skills. Learning a skill takes practice. Time spent by students during formal education practicing their
developer
expertise
0
programming skills is likely to total less than 60 hours. Six months into their first development job they
could very well have more than 600 hours of experience. Although students are unlikely to complete their
education with a lot of programming experience, they are likely to continue using the programming beliefs
and practices they have acquired. It is not the intent of this book to decry the general lack of good software
development training, but simply to point out that many developers have not had the opportunity to acquire
good habits, making the use of coding guidelines even more essential.
Can students be taught in a way that improves their general reasoning skills? This question is not directly
relevant to the subject of this book; but given the previous discussion, it is one that many developers will be
asking. Based on the limited researched carried out to date the answer seems to be yes. Learning requires
intense, quality practice. This would be very expensive to provide using human teachers, and researchers
are looking at automating some of the process. Several automated training aids have been produced to help
improve students’ reasoning ability and some seem to have a measurable affect.
[1434]
15.2.2 Cultural skills
Cultural skills include the use of language and category formation. Nisbett and Norenzayan
[1032]
provide
developer
language
and culture
792
catego-
rization
cultural differences
0
an overview of culture and cognition. A more practical guide to cultural differences and communicating
with people from different cultures, from the perspective of US culture, is provided by Wise, Hannaman,
Kozumplik, Franke, and Leaver.
[1509]
15.3 Creating experts
To become an expert a person needs motivation, time, economic resources, an established body of knowledge
to learn from, and teachers to guide.
One motivation is to be the best, as in chess and violin playing. This creates the need to practice as much
as others at that level. Ericsson found
[402]
that four hours per day was the maximum concentrated training
that people could sustain without leading to exhaustion and burnout. If this is the level of commitment, over
a 10-year period, that those at the top have undertaken, then anybody wishing to become their equal will have
to be equally committed. The quantity of practice needed to equal expert performance in less competitive
fields may be less. One should ask of an expert whether they attained that title because they are simply as
good as the best, or because their performance is significantly better than non-experts.
In many domains people start young, between three and eight in some cases,
[402]
their parents’ interest
being critical in providing equipment, transport to practice sessions, and the general environment in which to
98 v 1.2 June 24, 2009
15 Expertise Introduction
0
study.
An established body of knowledge to learn from requires that the domain itself be in existence and
relatively stable for a long period of time. The availability of teachers requires a domain that has existed long
enough for them to have come up through the ranks; and one where there are sufficient people interested in it
that it is possible to make as least as much from teaching as from performing the task.
The research found that domains in which the performance of experts was not significantly greater than
non-experts lacked one or more of these characteristics.
15.3.1 Transfer of expertise to different domains
Research has shown that expertise within one domain does not confer any additional skills within another
expertise
transfer to an-
other domain
domain.
[35]
This finding has been duplicated for experts in real-world domains, such as chess, and in
laboratory-created situations. In one series of experiments, subjects who had practiced the learning of
sequences of digits (after 50–100 hours of practice they could commit to memory, and recall later, sequences
containing more than 20 digits) could not transfer their expertise to learning sequences of other items.
[219]
15.4 Expertise as mental set
Software development is a new field that is still evolving at a rapid rate. Most of the fields in which expert
performance has been studied are much older, with accepted bodies of knowledge, established traditions, and
methods of teaching.
Sometimes knowledge associated with software development does not change wholesale. There can be
small changes within a given domain; for instance, the move from K&R C to ISO C.
In a series of experiments Wiley,
[1499]
showed that in some cases non-experts could outperform experts
within their domain. She showed that an expert’s domain knowledge can act as a mental set that limits the
search for a solution; the expert becomes fixated within the domain. Also, in cases where a new task does not
fit the pattern of highly proceduralized behaviors of an expert, a novice’s performance may be higher.
15.5 Software development expertise
Given the observation that in some domains the acknowledged experts do not perform significantly better
software de-
velopment
expertise
than non-experts, we need to ask if it is possible that any significant performance difference could exist
in software development. Stewart and Lusk
[1323]
proposed a model of performance that involves seven
components. The following discussion breaks down expertise in software development into five major areas.
1.
Knowledge (declarative) of application domain. Although there are acknowledged experts in a wide
variety of established application domains, there are also domains that are new and still evolving
rapidly. The use to which application expertise, if it exists, can be put varies from high-level design
to low-level algorithmic issues (i.e., knowing that certain cases are rare in practice when tuning a
time-critical section of code).
2.
Knowledge (declarative) of algorithms and general coding techniques. There exists a large body of
well-established, easily accessible, published literature about algorithms. While some books dealing
with general coding techniques have been published, they are usually limited to specific languages,
application domains (e.g., embedded systems), and often particular language implementations. An
important issue is the rigor with which some of the coding techniques have been verified; it often
leaves a lot to be desired, including the level of expertise of the author.
3.
Knowledge (declarative) of programming language. The C programming language is regarded as
an established language. Whether 25 years is sufficient for a programming language to achieve the
status of being established, as measured by other domains, is an open question. There is a definitive
document, the ISO Standard, that specifies the language. However, the sales volume of this document
has been extremely low, and most of the authors of books claiming to teach C do not appear to have
read the standard. Given this background, we cannot expect any established community of expertise in
the C language to be very large.
June 24, 2009 v 1.2 99
Introduction 15 Expertise
0
4.
Ability (procedural knowledge) to comprehend and write language statements and declarations that
implement algorithms. Procedural knowledge is acquired through practice. While university students
may have had access to computers since the 1970s, access for younger people did not start to occur
until the mid 1980s. It is possible for developers to have had 25 years of software development practice.
5.
Development environment. The development environment in which people have to work is constantly
changing. New versions of operating systems are being introduced every few years; new technologies
are being created and old ones are made obsolete. The need to keep up with development is a drain on
resources, both in intellectual effort and in time. An environment in which there is a rapid turnover in
applicable knowledge and skills counts against the creation of expertise.
Although the information and equipment needed to achieve a high-level of expertise might be available, there
are several components missing. The motivation to become the best software developer may exist in some
individuals, but there is no recognized measure of what best means. Without the measuring and scoring of
performances it is not possible for people to monitor their progress, or for their efforts to be rewarded. While
there is a demand for teachers, it is possible for those with even a modicum of ability to make substantial
amounts of money doing (not teaching) development work. The incentives for good teachers are very poor.
Given this situation we would not expect to find large performance differences in software developers
through training. If training is insufficient to significantly differentiate developers the only other factor is
individual ability. It is certainly your author’s experience— individual ability is a significant factor in a
developer’s performance.
Until the rate of change in general software development slows down, and the demand for developers falls
below the number of competent people available, it is likely that ability will continue to the dominant factor
(over training) in developer performance.
15.6 Software developer expertise
Having looked at expertise in general and the potential of the software development domain to have experts,
developer
expertise
we need to ask how expertise might be measured in people who develop software. Unfortunately, there are no
reliable methods for measuring software development expertise currently available. However, based on the
previously discussed issues, we can isolate the following technical competencies (social competencies
[1024]
are not covered here, although they are among the skills sought by employers,
[81]
and software developers
have their own opinions
[850,1293]
):
• Knowledge (declarative) of application domain.
• Knowledge (declarative) of algorithms and general coding techniques.
• Knowledge (declarative) of programming languages.
•
Cognitive ability (procedural knowledge) to comprehend and write language statements and declara-
tions that implement algorithms (a specialized form of general analytical and conceptual thinking).
•
Knowledge (metacognitive) about knowledge (i.e., judging the quality and quantity of one’s expertise).
Your author has first-hand experience of people with expertise individually within each of these components,
while being non-experts in all of the others. People with application-domain expertise and little programming
knowledge or skill are relatively common. Your author once implemented the semantics phase of a CHILL
(Communications HIgh Level Language) compiler and acquired expert knowledge in the semantics of that
language. One day he was shocked to find he could not write a CHILL program without reference to
some existing source code (to refresh his memory of general program syntax); he had acquired an extensive
knowledge based of the semantics of the language, but did not have the procedural knowledge needed to
write a program (the compiler was written in another language).
0.6
0.6
As a compiler writer, your author is sometimes asked to help fix problems in programs written in languages he has never seen
before (how can one be so expert and not know every language?). He now claims to be an expert at comprehending programs written in
unknown languages for application domains he knows nothing about (he is helped by the fact that few languages have any truly unique
constructs).
100 v 1.2 June 24, 2009
Không có nhận xét nào:
Đăng nhận xét