1.
Roehm,
Tiarks,
Koschke,
and
Maalej

2. Outline
of
the
Talk
1
MoAvaAon
2
Study
Design
3
Main
Findings
4
Next
Steps
2

3. Why
Should
we
Comprehend
this?
3

4. ObservaAons
on
Program
Comprehension
Limited
knowledge
of
A
mature
research
field
pracAce
• Over
30
years
of
research
• Previous
studies
are:
• Important
ac6vity
in
• Rela6vely
old
(outdated?)
so8ware
engineering
and
• Handle
specific
ques6ons
maintenance
• Have
methodological
• Theories
on
program
limita6ons
(e.g.
comprehension
and
conducted
with
students
research-­‐based
tools
to
or
in
lab
seKngs)
support
developers
Does
the
state
of
the
pracAce
match
with
the
state
of
the
art?
4

5. Goal:
QualitaAvely
explore
how
program
comprehension
is
done
in
industry
5

6. Outline
of
the
Talk
1
MoAvaAon
2
Study
Design
3
Main
Findings
4
Next
Steps
6

7. Research
QuesAons
Which
strategies
(including
steps
and
ac6vi6es)
do
developers
use
in
order
to
comprehend
so8ware?
Which
sources
of
informaAon
Which
tools
do
developers
do
developers
use
during
use
when
understanding
program
comprehension?
programs
and
in
which
way?
7

8. Research
Method
Field
observaAons
Contextualized
semi-­‐
with
think
aloud
structured
interviews
1
2
Which
and
When
How
and
Why
Ques+ons
Ques+ons
8

9. Data
Analysis
ObservaAon
logs
Itera6ve
Frequencies
and
interview
manual
minutes
clustering
ABC
BBD
BDA
18
findings
23
hypotheses
AAAAA
BBBBB
CCCCC
9

10. Reliability
Measures
Triangula6on
of
data
sources
Independent
peer
observa6ons
Dry
runs
Peer
debriefing
Double-­‐checking
by
par6cipants
10

11. Research
Subjects
SelecAon
Criteria
ParAcipants
• Inclusion
criteria
• 28
subjects
• Developers
working
for
• Between
1,5
and
19
years
so8ware
companies
of
development
experience
• Spend
most
of
their
work
• 7
European
companies
6me
on
source
code
• Different
domains
and
• Exclusion
criteria
technologies
• Students
and
researchers
• Random
tasks,
each
includes
program
comprehension
11

12. Outline
of
the
Talk
1
MoAvaAon
2
Study
Design
3
Main
Findings
4
Next
Steps
12

13. Comprehension
Strategies
Finding
Part.
Comp.
Employ
a
recurring,
structured
comprehension
1
26
7
strategy
depending
on
context
2
Follow
a
problem-­‐soluAon-­‐test
work
pa`ern
18
5
Debug
applica6on
to
elicit
runAme
3
16
5
informaAon
Interact
with
UI
to
test
expected
program
4
17
5
behavior
13

14. Developers
Interact
with
UI
to
Test
Expected
Program
Behavior
„We
passed
two
6mes
in
this
loop
because
of
two
event
categories
displayed
in
the
UI”
Enter
values
in
UI
form
and
verify
they
are
stored
in
database
14

15. Comprehension
Strategies
(ctd.)
Finding
Part.
Comp.
Take
notes
to
reflect
mental
model
and
record
5
9
4
knowledge
Iden6fy
starAng
point
for
comprehension
and
6
10
5
filter
irrelevant
code
based
on
experience
7
Establish
and
test
hypotheses
9
5
Clone
to
avoid
comprehension
and
minimize
8
14
6
effort
15

16. Developers
Clone
to
Avoid
Comprehension
and
Minimize
Effort
Clone
to
avoid
comprehension
Worried
about
breaking
the
system
1.
Copy
several
methods
2.
Comment
all
of
them
3.
Repeatedly
uncomment
methods
in
compiler
warnings
16

17. InformaAon
Sources
Finding
Part.
Comp.
Source
code
is
more
trusted
than
1
21
6
documenta6on
CommunicaAon
is
preferred
over
2
17
5
documenta6on
3
Standards
facilitate
comprehension
12
6
Cryp6c,
meaningless
names
hamper
4
10
6
comprehension
RaAonale
and
intended
usage
is
5
10
5
important
but
rare
informa6on
6
Real
usage
scenarios
are
useful
but
rare
5
4
17

18. Tool
Usage
Finding
Part.
Comp.
Dedicated
program
comprehension
1
28
7
tools
are
not
used
Tools
with
redundant
features
are
used
2
5
4
in
parallel
to
IDE
Compiler
is
used
to
elicit
structural
3
5
4
informaAon
Tool
features
for
comprehension
are
4
3
3
unknown
18

19. Program
Comprehension
Tools
not
Used
None
of
developers
used
dedicated
program
comprehension
tools
such
as
visualiza6on,
concept
loca6on
or
metric
calcula6on
tools
Comprehension
features
(e.g.
indexing
or
call
tree
viz.)
were
available
but
unknown
19

20. Outline
of
the
Talk
1
MoAvaAon
2
Study
Design
3
Main
Findings
4
Next
Steps
20

21. ImplicaAons
for
PracAAoners
Define
coding
style
&
Evaluate
research
1
2
naming
conven6ons
proposals
Deal
with
„feature
3
4
Inves6gate
reasons
overload“
behind
gap
21

22. ImplicaAons
for
Researchers
Think
of
the
developer
as
a
user
Revisit
agendas
considering
our
hypotheses
Inves6gate
reasons
behind
gap
between
research
and
prac6ce
22

23. Summary
of
the
Talk
1
We
observed
and
interviewed
28
professional
developers
to
study
comprehension
strategies,
informa6on,
and
tools.
2
Developers’
comprehension
strategies
depend
on
context.
They
interacted
with
UI
to
test
expected
program
behavior.
3
Developers
cloned
pieces
of
code
to
avoid
comprehension.
They
do
not
use
dedicated
program
comprehension
tools.
4
Prac66oners,
tool
vendors,
and
researchers
need
to
further
inves6gate
the
gap
between
research
and
prac6ce
23

24. How
Do
Professional
Developers
Comprehend
So_ware?
Tobias
Rebecca
Rainer
Walid
Roehm
Tiarks
Koschke
Maalej
24