How Do Professional
Developers Comprehend
Software ?
Ninad Malvankar
2
Program Comprehension
 Important activity in software maintenance.
 Consumes about half of the time spent by
developers in maintenance.
 The strategies followed to understand software
might vary among developers depending upon
their personality, experience, skills, and the task at
hand.
3
Research Questions (RQ)
 RQ1: Which strategies (including steps and
activities) do developers follow to comprehend
programs?
 RQ2: Which sources of information do developers
use during program comprehension?
 RQ3: Which information is missing?
 RQ4: Which tools do developers use when
understanding programs and how?
4
Research Method
 The developers were observed in their real work
environment.
 The tasks were not predefined.
 The tasks were chosen by the participants
themselves.
 The method includes observation session (45
minutes) and interview session (45 minutes).
5
Observation
 A single participant was observed for 45 minutes.
 During the observation session they used the
think-aloud method i.e. they asked the participants
to comment on what they are doing, to understand
what is going on and get access to thoughts in
participants mind.
 They noted the participants actions and quotes.
6
Observation
7
Interview
 A single participant was interviewed for 45 minutes
after the observation session.
 The interview focused on exploring how and why
questions like “Why did you debug?”, “How did you
realize that method Y is buggy?”, etc.
 They were basically interested in getting the
answers to the research questions.
8
Testing the Method
 Before they observed programmers in the industry
they conducted a test session with a postgraduate
student and observed him.
 They found that they had too many questions and
dropped less important ones in order to stick to the
timeframe of 45 minutes.
 They realized that some questions target the same
information and so they merged them.
9
Evaluation
 They summarized each session by collecting
interesting observations i.e. those that were not
expected, occurred in a similar way, or differed
among participants.
 The validity of the single result is strengthened if it
is both observed and reported.
10
Participants
 They excluded students and university
researchers, from the study as they wanted to
study industry practice.
 They allowed participants with different tasks,
different project roles, different experience,
different technology used and different company
size in order to explore program comprehension as
broad as possible .
 They studied 28 participants.
11
Findings
 Comprehension Strategies
(S1)Employ a recurring, structured comprehension
strategy depending on context.
Hypothesis 1: Developers usually follow a recurring,
structured comprehension strategy that varies with
the type of task, developer personality, the amount
of previous knowledge about the application and the
type of application.
12
Findings
 Comprehension Strategies
(S2) Follow a problem-solution-test work pattern.
Hypothesis 2:For tasks including changing source
code, developers employ a work pattern with three
steps (a)Identifying the problem, (b)applying a
solution, (c)testing the correctness of the solution.
13
Findings
 Comprehension Strategies
(S3) Interact with UI to test expected program
behavior.
Hypothesis 3:Developers interact with the user
interface of the software to test if the application
behaves as expected and to find starting points for
further inspection.
14
Findings
 Comprehension Strategies
(S4)Debug application to elicit runtime information.
Hypothesis 4:Developers frequently debug the
application to acquire runtime information.
15
Findings
 Comprehension Strategies
(S5) Clone to avoid comprehension and minimize effort.
Hypothesis 5: Developers try to avoid comprehension by
cloning pieces of code if they cannot comprehend all
possible consequences of changes.
Hypothesis 6: Developers prefer a unified documentation
structure to simplify finding information needed for
comprehension.
Hypothesis 7: Developers usually want to get their tasks
done rather than comprehend software.
16
Findings
 Comprehension Strategies
(S6)Identify starting point for comprehension and
filter irrelevant code based on experience.
Hypothesis 8:Experience of developers plays an
important role in program comprehension activities
and helps to identify starting points for further
inspection and to filter out code locations that are
irrelevant for the current task.
17
Findings
 Comprehension Strategies
(S7)Establish and test hypotheses.
Hypothesis 9:Developers comprehend software by
asking and answering questions and establishing
and testing hypotheses about application behaviour.
18
Findings
 Comprehension Strategies
(S8)Take notes to reflect mental model and record
knowledge.
Hypothesis 10:Some developers use temporal notes
as comprehension support. This externalized
knowledge is only used personally. It is neither
archived nor reused.
19
Findings
 Information Sources
(I1)Source code is more trusted than
documentation.
Hypothesis 11:Source code is considered a more
credible source of information than written
documentation, mainly because documentation is
often non-existent or outdated.
20
Findings
 Information Sources
(I2) Communication is preferred over
documentation.
Hypothesis 12:Communication with colleagues is
more important source of information than written
documentation as answers can be tailored to the
information seekers.
21
Findings
 Information Sources
(I3) Standards facilitate comprehension.
Hypothesis 13:The consistent use of naming
conventions and a common architecture allows
developers to become familiar with an application
quickly and makes program comprehension
activities easier and faster.
22
Findings
 Information Sources
(I4) Cryptic, meaningless names hamper
comprehension.
Hypothesis 14:Cryptic, non-semantic names
hamper understanding a piece of code.
Hypothesis 15:Naming conventions can help to
mitigate this effect.
23
Findings
 Information Sources
(I5) Rationale and intended usage is important but rare
information.
Hypothesis 16:Knowledge about rationale of the
implementor and intended ways of using a piece of code
help to comprehend software but this information is
rarely documented.
Hypothesis 17:There is a gap between the interest of
developers and the lack of documenting it for their own
code.
24
Findings
 Information Sources
(I6) Real usage scenarios are useful but rare.
Hypothesis 18:The way in which end users use an
application is a helpful context information in
program comprehension.
Hypothesis 19:In many cases this information is
missing.
25
Findings
 Tool Usage
(T1) Dedicated program comprehension tools are
not used like software metric tools.
Hypothesis 20:Industry developers do not use
dedicated program comprehension tools developed
by the research community.
26
Findings
 Tool Usage
(T2)Standalone tools are used in addition to IDEs.
Hypothesis 21:During comprehension tasks, IDE
and specialized tools are used in parallel by
developers, despite the fact that the IDE provides
similar features.
27
Findings
 Tool Usage
(T3)Compiler is used to elicit structural information.
Hypothesis 22:The compiler is used by some
developers to elicit structural information such as
dependencies and usage locations of code
elements.
28
Findings
 Tool Usage
(T4)Tool features for comprehension are unknown.
Hypothesis 23:Developers do not know some
standard features of tools.
29
Limitations and Threats to Validity
 In 45 minutes they can only observe a fraction of
developer’s work day. So they might have missed
certain types of tasks, comprehension strategies,
information sources or tools.
 Participants might have behaved differently
because they were observed.
 There might be misinterpretations of think-aloud
comments and interview answers due to
insufficient language skills.
30
Conclusion
 In this study 28 developers from software industry were
observed to get insights into the state of the practice in
program comprehension
 Developers sometimes try to avoid comprehending
programs, instead just clone the source code and adapt it to
fulfill the task at hand.
 Developers frequently debug the application for program
comprehension.
 Most developers choose from a set of structured
comprehension strategies, depending on their work context.
 Program comprehension tools are either unknown or rarely
used.
 This reveals a gap between the state of the art program
comprehension research and the state of practice in industry.
GROPG: A Graphical
On-Phone Debugger
32
Debugging
 Common activity during software development and
maintenance.
 A study found out that professional software
developers use debuggers for general program
comprehension tasks [2].
 Debugging mobile phone applications is hard, as
current debugging techniques either do not provide
powerful debugging features such as graphical
user interface or require multiple computing
devices.
Debugging Techniques For Mobile
Application
33
 Attach the debugger to a mobile phone emulator
or virtual device.
 All mobile application platforms including Android,
iOS, and Windows phone provide such emulators.
 Emulators are useful but not sufficient, as they do not
simulate all phone features precisely.
Debugging Techniques For Mobile
Application
 Attach the desktop debugger to a phone, e.g. via
USB cable.
 This technique requires two connected computing
devices, which is called as the two-device
requirement.
34
Debugging Techniques For Mobile
Application
35
 Debug the application on the phone itself.
 This technique requires a single device i.e. a mobile
phone.
 This techniques are text-based or do not have a user
interface that gives the programmer some features to
view the debuggee’s code location, memory values
etc.
36
Challenges
 Small Screen Size of phones.
 Desktop Debuggers have user interface optimized
for keyboard shortcuts, which do not exists on
phones.
 User interface libraries that desktop debuggers are
constructed from typically do not exist on phones.
37
Android
 All the android applications are written in Java.
 Android runs an application only if it is digitally
signed.
 Developers can compile and sign an application
either for release or for debugging.
 If an application is compiled for release mode,
Android prevents it from being debugged.
38
Android
 Android consists of operating system services, a
Linux-based kernel and the Dalvik virtual machine.
 A debugger can communicate with Dalvik via the
Android Debug Bridge ADB, which consists of
client, server and daemon.
 Each android device runs a daemon which can be
discovered by the server. The server can be
discovered by the clients, which are typically
started by tools such as a debugger.
39
Desktop based Debugger
40
GROPG
 GROPG re-uses many components of the twodevice setup.
 The debugger and Dalvik communicate via ADB
and the standard debugging interfaces JDWP and
JDI.
 Instead of USB cable, ADB components
communicate directly over a network socket.
 Only local connections are allowed to this socket to
prevent external machine access.
 Recent android versions don not allow changing
ADB communication from USB to network socket,
for this we require root access.
41
GROPG
42
GROPG
 GROPG displays itself over the debuggee
application.
 Android normally does not allow an application to
display itself on top of another application.
 GROPG circumvents this limitation by injecting
itself into the Android’s notification system, as
notifications are used to announce on top of user
interface of currently executing application for a
few seconds.
 So just before the notification display time expires,
GROPG enters itself again into the notification
queue ensuring continuous display on top of the
debuggee application .
43
44
Memory consumption
45
Less Steps Required
46
Conclusion
 GROPG has a higher memory overhead due to the
addition of a graphical front-end.
 GROPG reduces debugging time by up to 2/3.
 Future work would be to integrate GROPG with onphone coding, to create a full on-phone IDE.
47
References
[1] G. C. Murphy, M. Kersten, and L. Findlater, “How are Java
software developers using the Eclipse IDE?” IEEE Software,
vol. 23, no. 4, pp. 76–83, Jul. 2006.
[2] T. Roehm, R. Tiarks, R. Koschke, and W. Maalej, “How do
professional developers comprehend software?” in Proc. 34th
ACM/IEEE International Conference on Software Engineering
(ICSE). IEEE, Jun. 2012, pp. 255– 265.
[3] N. Tillmann, M. Moskal, J. de Halleux, and M. Fa ̈hndrich,
“Touchdevelop: Programming cloud-connected mobile devices
via touchscreen,” in Proc. 10th SIGPLAN ONWARD. ACM,
2011, pp. 49–60.
48
Questions?