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

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.

Interview

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.

33Debugging Techniques For Mobile Application

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.

34Debugging 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.

35Debugging Techniques For Mobile Application

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

GROPGGROPG re-uses many components of the two-

device 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

GROPGGROPG 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

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 on-

phone coding, to create a full on-phone IDE.

Conclusion

47

[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 Lhndrich, “Touchdevelop: Programming cloud-connected mobile devices via touchscreen,” in Proc. 10th SIGPLAN ONWARD. ACM, 2011, pp. 49–60.

References

48

Questions?