Future of Software Rejuvenation : Survey among practitioners

In this survey we asked the participants how they currently use and experience software rejuvenation tools, and what they expect from these tools in the future. The respondents indicated that they are very familiar with the issues addressed by software rejuvenation, and most of them have used rejuvenation tools themselves. They also rated their proficiency, the maturity of the tools, the time it took to learn them, and their overall rating of the experience with each tool. This revealed a correlation between proficiency with a tool and its rating, as well as between proficiency and maturity. No correlation was found between the time it takes to learn a tool and the tool's rating, indicating that learning time is not considered a primary concern. The primary identified goals of software rejuvenation are to replace outdated libraries and update to a newer version of the same programming language. Software architects and developers typically initiate rejuvenation as part of software maintenance or when a business opportunity arises. A recurring concern is that rejuvenation is perceived as too costly (in time and money) or too risky, or offering unclear value. This causes software maintenance to be postponed, worsening the problem over time. The most commonly used programming languages are C, C++, C#, Java, and Python. These are frequently combined in codebases, with common combinations being Python with C++ or Java and C with C++. Older versions of these languages, such as C99, C++11, Java SE 8, or even Python 2 (now deprecated), are often used. Respondents plan to add new versions of the same language, such as C++23, typically updating about a year after the release or when a new project begins. They also plan to remove older versions, but they are uncertain if these plans will be realized. DSLs are commonly found in codebases, often used in the build process or for code generation. There is a large variety in build systems, with no dominant choice. When asked about the preferred way to write a software rejuvenation script or program, respondents showed a clear preference for either the same language as the codebase, a rejuvenation-specific DSL, or Python. A common remark is that the choice of language is not very important as long as it is easy to learn or the users are already familiar with it. There is a wide range of analyses that can be performed on a codebase, and all are seen as necessary. Participants prefer to access analysis results as visualizations rather than as lists or programmatically via an API. The goals for code transformation are clear: modernize the code, update the programming language, or enhance the code structure. Updating comments and documentation within the code is also considered necessary. The same holds for code style, which is often en-forced either through tools or peer review. Rejuvenation tools are expected to update or move comments in tandem with code transformations. When code analysis is inconclusive, rejuvenation tools are expected to either not perform the transformation or prompt the user for a decision. Each intermediate step in a rejuvenation pipeline is expected to compile and build, and preferably also pass all static code checks. The most critical requirement for software rejuvenation tools is functional correctness, while updating comments, despite deemed necessary, is near the bottom of the priority list when weighed against other objectives. Rejuvenation tools are preferably implemented using plugin-based or pipeline software architectures. For these options, rejuvenation tool developers are willing to contribute by adding support for a new language, a new analysis, or a new transformation step. The preferred license for rejuvenation tools is either a permissive open-source license or a hybrid of open-source and proprietary. Many rejuvenation tool developers indicated that they would be willing to modify their tool to integrate it into a generic software rejuvenation platform.