Naveen Kulkarni received  his  doctorate in Computer Science and Engineering (CSE). His research work was supervised by Prof.Vasudeva Varma. Here’s a summary of his research work on Code summarization for opportunistic reuse in large software systems:

Developers perform a wide variety of tasks during software maintenance. The most common tasks are documentation, bug fixing, enhancing capabilities, removing obsolete capabilities, and optimizations. Each task varies in complexity and effort. Developers spend significant time acquiring the software system’s knowledge. Specifically, they find comprehension of collected information laborious and often repetitive. This difficulty is due to the dispersed information across multiple artifacts such as source code, unit tests, bug reports, API documentation, commit history, and developer discussions. Developers’ comprehension effort gets confounded as the number of artifacts increases. Also, complete comprehension is difficult as software systems grow and get more distributed. Due to this, developers have a fragmented or incomplete understanding of the software system. To overcome this, they adopt tactical strategies to familiarize themselves with the program. They either read code, add trace statements, use debuggers, establish, and test hypotheses, or observe the behavior. Due to this, the changes are tedious and are of lower quality. So, supporting developers to acquire task-specific knowledge rapidly is essential to maintain a software system effectively.
Developers choose to read software code. They do so due to a lack of time and face minimum barriers. Developers read code on a need-basis without any plan — opportunistic. They choose either case-based or scavenging approaches. Large-scale studies have observed that developers read code despite the availability of modern tools and Integrated Development Environment (IDE). While code reading is prevalent among developers, the effectiveness of approaches followed by them is unknown. So, we study the effectiveness of reading code in the context of reusing an external module, which is a common developer task.
Reuse is a complex task, but developers are still required to integrate an external module rapidly.
Observing developers undertake the reuse task is difficult due to the unplanned nature of the task. So, analyzing the historical bug reports and commit history helps us reason about the effectiveness of code reading. We observed reuse of the JMapViewer module in two independently managed open-source software applications — Mobile Atlas Creator and JTileDownloader. Based on the bug reports and large commits, we conjecture that comprehension was limited. It was to the extent required to accomplish the integration. We observed many inconsistencies, emergent behavior, conflicting scenarios, and fragility in the software structure. From this study, we infer that developers limit knowledge acquisition in an opportunistic task. Furthermore, we also conclude that the issue is due to the information overload they face when reading code.
There is a growing interest in understanding developers’ tasks and how they comprehend code.  Nevertheless, little is known about developers’ information needs when reading code. For example, how do developers locate concepts in a new program? What information do they seek to assess the impact of a change? What knowledge about the system do they need to triage bugs? How do they decide where to start for root cause analysis? When working with code, developers are constantly engaged in reasoning about the choices, implications, purpose, relevance, and expectations. In doing so, they assess a code fragment’s relevancy to the task. Typically, a comprehension task being with an information-seeking activity.
We find the current developer toolsets fall short in assisting developers in reducing the information
overhead they face during comprehension. When developers read a code, they create rich mental models of the program structure. However, these models are volatile and have no formal methods to record and share among developers. As there are no records, developers repeatedly read the same code and rebuild the mental model again. Having to repeat this across multiple source code is tedious, more so if the code is unfamiliar.
Recently, researchers are examining large software projects using Mining Software Repositories (MSR) techniques to address a variety of Software Engineering questions. Overwhelmingly, recent research studies have focused on what can happen or why it happens. However, when reading code, questions related to what is happening are essential. So, we explored how to assist a developer in reading code by identifying and extracting task-specific information from software artifacts. We base our approach on the program comprehension model and the program navigation models. These models suggested that developers use beacons or cues to establish the relevance of a piece of information with a task. For example, for a developer investigating a message printed on the console, the phrases like “print to,” “write to,” or “log” in the source code text can draw their attention. We consider the opportunistic process inherently depends on the cues, and developers often forage them within the artifacts. Even though cues influence a developer’s perception, their cue choices and tool (IDE and code editors) support for cue-based knowledge acquisition is unknown.
Being familiar with different kinds of cues will help the developers comprehend a program faster.
However, developers fail to recognize the relevant cues because (a) there are many cues, and (b) they are unfamiliar with the artifacts. As all developers read code, we hypothesize that all developers follow similar cues while reading an unfamiliar code without advanced tools. We conducted two independent studies to understand their cue choices. Specifically, we studied whether developers’ cue choices differ with the task, experience, and tool. First, in a controlled experiment, we studied the code reading habits of 15 developers categorized into three groups based on software development experience. We provided participants with two comprehension tasks from JEdit — an open-source text editing software. We chose JEdit as it was unfamiliar to all the participants. During the experiment, participants recorded their understanding after reading the code, identify the artifacts they referred to, and the time taken to complete the task. We found that participants within a category followed similar cues, but their cue choices varied across categories.
Their cue choices were task-dependent. Experienced developers not just located more cues but also followed them across multiple artifacts. They took more time for comprehension than novice developers. They gave equal importance to both lexicon and non-lexicon cues. We also found that participants in each category preferred specific cues. These observations make us conclude that there is a trade-off among available cues for the given task.
We investigated whether an IDE could influence a developer’s cue choices. We collected six years of developer’s interaction histories while fixing bugs for four Eclipse projects for our observation. The interaction data contains all the developer activities, such as navigations, search, files opened, within an IDE for a task. We computed the average selection and the average selection interest from interaction data to understand developers’ navigation behavior when fixing bugs in the IDE.
We found the average selection was high, and the average selection interests were the same irrespective of a developer’s familiarity with the code. This observation suggests that Eclipse project developers prescribed no criteria when navigating within an IDE. So, either these developers ignored cues from the IDE, or the cues were not significant to influence their navigation behavior. We also found that these developers had specific choices of views in Eclipse IDE. They chose generalized views like Package Explorer frequently as against specialized views like Call Hierarchy. We consider the lack of better cues in specialized views to be the reason. We suggest the need for further investigation to improve task-specific IDE views based on the developers’ cue choices.
When faced with unfamiliar code, novice developers find comprehension overwhelming. In our previous study, we observed that novice developers skip many cues and revisit the code often. So, we generated program summaries using a task-specific cue model to help them. Program summarization is an approach to summarize a program by applying text summarization techniques.
We generated contextual summaries using the task-specific cue model. Our previous study found that both experienced and novice developers recorded summaries were of similar length. So, we synthesized summaries that were 10% of lines of code comprehended. The synthesized summaries were 80% similar to the developer recorded summaries. These results suggest that the cue model can significantly improve the quality of program summaries. The encouraging results suggest that we can aid novice developers in reading code faster through contextual program summaries.
Finally, we demonstrate how a task-specific cue model can be adapted to solve other challenges  developers face. We extend the task-specific cue model to help developers perform impact analysis faster and improve code readability. We observe that accepting or rejecting a patch or a pull request takes a long time due to slower comprehension. Summarizing the changes can reduce this time and can automate the impact set preparation. We used the cue model to construct the change-set and summarized the changes. The summarized change-set helps reduce the repository owner’s cognitive load to analyze the patch or pull request changes. This approach can encourage better collaboration among developers due to faster reviews. There are not enough approaches to enforce good code readability rules apart from common lint tools. Though static and dynamic code assessment provides code complexity measures, they fall short in measuring the quality of identifiers or comments. We used the clue model improve code readability quality by locating ambiguous identifiers.