Exploiting Defect Prediction for Automatic Software Repair (Fixie)
Lead Research Organisation:
Lancaster University
Department Name: Computing & Communications
Abstract
Software is now at the heart of almost everything we do in the world. This software remains largely handmade, and as such, is prone to defects. Testing detects only a sub-set of software defects with the rest laying dormant, sometimes for years. When these defects emerge in software systems the safety and business consequences can be severe. Software failures and their damaging consequences are regularly reported in the press. Finding and fixing defects has been an intransigent problem over many years. The traditional approach to this problem relies on finding defects during testing then developers manually fixing those defects afterwards.
In this project we establish a new technique to automatically fix predicted defects in software code before testing. We use machine learning-based defect prediction information to generate automatic fixes using Genetic Improvement. Our approach aims to offer developers effective fixes to code which is predicted as defective. A higher proportion of the fixes our approach offers to developers should be acceptable, generated quicker and available earlier in the development cycle than previous attempts at automated repair. Importantly, our approach targets a wider pool of defects as it specifically includes targeting those dormant defects which are not identified by testing.
Using our approach the developer will always remain in control of the code produced. Fixes are suggested, and the developer is the 'gate-keeper', deciding if a suggested fix is accepted, rejected, or can itself be modified to improve the code. One of the tangible outputs of the project will be a defect fixing tool (Fixie), which will provide support to developers in their daily coding activities. The tool will be developed in collaboration with several industrial partners and will be empirically evaluated throughout the project.
In this project we establish a new technique to automatically fix predicted defects in software code before testing. We use machine learning-based defect prediction information to generate automatic fixes using Genetic Improvement. Our approach aims to offer developers effective fixes to code which is predicted as defective. A higher proportion of the fixes our approach offers to developers should be acceptable, generated quicker and available earlier in the development cycle than previous attempts at automated repair. Importantly, our approach targets a wider pool of defects as it specifically includes targeting those dormant defects which are not identified by testing.
Using our approach the developer will always remain in control of the code produced. Fixes are suggested, and the developer is the 'gate-keeper', deciding if a suggested fix is accepted, rejected, or can itself be modified to improve the code. One of the tangible outputs of the project will be a defect fixing tool (Fixie), which will provide support to developers in their daily coding activities. The tool will be developed in collaboration with several industrial partners and will be empirically evaluated throughout the project.
Planned Impact
The impact of high-quality software development cannot be underestimated as so many human activities rely on software these days. However, writing software that is correct, or even largely defect-free is extremely difficult. It is estimated that most software packages contain a large number of latent or dormant defects.
Defects can be identified by test cases which fail when the code is executed. But by using the propensity of code to be defective, we are able to identify and fix defects earlier in the development cycle, resulting in less defective code and software which is delivered quicker and at a reduced cost.
It is important to emphasise that we are advocating a system that guides the software developer. Our vision is to build a tool which will assist software developers but automatically suggest corrections to predicted defects. This will be similar to a spell checker in a word processor, i.e. it is semi automated decision support. A system which leaves the developer in full control of the code is more likely to have up-take in the community and therefore longer term impact than a tool which boasts full-automation.
This project builds on two existing successful pieces of software; the ELFF tool which brings possible bugs to the attention of the developer, and the JM tool which fixes bugs overnight. By bringing these tools together we can exploit the synergy of these two methodologies.
The cost of production software is high and so our approach is likely to reduce the cost of producing software in the first place. In addition our approach could reduce the overall time and cost to fix defects in already-released software which were not detected at release time.
Defects can be identified by test cases which fail when the code is executed. But by using the propensity of code to be defective, we are able to identify and fix defects earlier in the development cycle, resulting in less defective code and software which is delivered quicker and at a reduced cost.
It is important to emphasise that we are advocating a system that guides the software developer. Our vision is to build a tool which will assist software developers but automatically suggest corrections to predicted defects. This will be similar to a spell checker in a word processor, i.e. it is semi automated decision support. A system which leaves the developer in full control of the code is more likely to have up-take in the community and therefore longer term impact than a tool which boasts full-automation.
This project builds on two existing successful pieces of software; the ELFF tool which brings possible bugs to the attention of the developer, and the JM tool which fixes bugs overnight. By bringing these tools together we can exploit the synergy of these two methodologies.
The cost of production software is high and so our approach is likely to reduce the cost of producing software in the first place. In addition our approach could reduce the overall time and cost to fix defects in already-released software which were not detected at release time.
Publications
Al Debeyan F
(2024)
The impact of hard and easy negative training data on vulnerability prediction performance
in Journal of Systems and Software
Bowes D
(2020)
BugVis
Kirbas S
(2021)
On The Introduction of Automatic Program Repair in Bloomberg
in IEEE Software
Nagaria B
(2022)
How Software Developers Mitigate Their Errors When Developing Code
in IEEE Transactions on Software Engineering
Nagaria B
(2020)
Reducing Software Developer Human Errors by Improving Situation Awareness
in IEEE Software
Nowack V
(2020)
Exploiting fault localisation for efficient program repair
Nowack V
(2021)
Expanding Fix Patterns to Enable Automatic Program Repair
Description | Achievement 1: We reviewed how developers are considered in APR research by analysing how human factors are treated in 260 studies of APR. Over half of the 260 studies were motivated by a problem faced by developers (e.g., the difficulty associated with fixing faults). Despite these human-oriented motivations, fewer than 7% of the 260 studies included a human study. We looked in detail at these human studies and found their quality mixed (for example, one human study was based on input from only one developer). Our results suggest that software developers are often talked about in APR studies, but are rarely talked with. Achievement 2: Our survey of 386 software developers investigated their bug finding and fixing practices and experiences, and their instinctive attitudes towards APR. We found that bug finding and fixing is not necessarily as onerous for developers as has often been suggested, being rated as more satisfying than developers' general work. The fact that developers derive satisfaction and benefit from bug fixing indicates that APR adoption is not as simple as APR replacing an unwanted activity. When it comes to potential APR approaches, we find a strong preference for developers being kept in the loop (for example, choosing between different fixes or validating fixes) as opposed to a fully automated process. This suggests that advances in APR should be careful to consider the agency of the developer, as well as what information is presented to developers alongside fixes. It also indicates that there are key barriers related to trust that would need to be overcome for full scale APR adoption. Achievement 3: We report significant findings in terms of how to ensure that APR is delivered in a form attractive to software developers in industry. We conducted qualitative research (focus groups with developers) into automatic program repair (APR) at our partner company - Bloomberg. From the focus groups with developers who had used Fixie, we found particular concern with the pragmatic aspects of APR, such as how and when fixes were presented to them. Based on our findings, we make a series of recommendations to inform future APR development, highlighting how APR tools should 'start small', be customisable, and fit with developers' workflows. Achievement 4: The Fixie project has also made significant technical progress to improve the number and type of bugs that current APR can successfully fix. We used a fix pattern approach to further enable APR by automatically identifying new fix patterns and their concrete variants via clustering. We identified 15 new fix patterns and 12 repetitive concrete pattern variants. Our results will enable APR tools to reduce the search space of possible fixes enabling more efficient APR. We have developed a new Fixie APR tool incorporating these new fix patterns which we are now in the process of evaluating. In addition we also found that current tools are weak at generating multiline patches and synthesising new code especially when wrapping existing code. |
Exploitation Route | Our results are of most relevance to the software industry. APR is very attractive to industry as a way of cutting time that developers spend fixing bugs. Our intense collaboration with our project partner Bloomberg has resulted in Bloomberg taking up APR and establishing a group of developers working to integrate APR into the software development pipeline. This means that our work will likely influence software engineering in industrial software engineering. Our results are also very relevant to academic researchers in APR. There is much research interest in automated coding techniques (more so since the co-pilot has been made available). In the UK there are other research groups that the Fixie project has developed connections with (e.g. the CREST group at UCL) for taking the Fixie outcomes further in the future. |
Sectors | Digital/Communication/Information Technologies (including Software) |
Description | The biggest direct impact that the Fixie project has had so far is at our main collaborating partner company (Bloomberg). The Fixie project brought APR to the attention of Bloomberg and motivated the company to set up an APR development project. Two of the Fixie project researchers were seconded to the Bloomberg APR team to assist in the technology transfer of Fixie knowledge and outputs. As a result, the Bloomberg Fixie team developed customised Fixie tools to use in their software engineering pipeline. The outcomes of this partnership were documented in two papers that were published in Industry streams (one in IEEE Software, the other at the ACM FSE conference). Since us publishing an account of the Fixie APR partnership with Bloomberg the paper has received 45 citations since 2021. Indicating the amount of interest and traction there is for this industry relevant APR outcome from Fixie. This partnership is continuing to form a valuable seed for more industrial implementation of Fixie outcomes. The Fixie project has been invited to speak about this Bloomberg collaboration at a prestigious APR CREST workshop at UCL, gaining additional exposure to the APR academic and industrial community. In addition the Bloomberg team have furthered their interest and work in APR as a result of the Fixie project, with the Bloomberg lead Serkan Kirbas going on to give a variety of industrial talks at various software engineering forums discussing the Fixie collaboration and the work that Bloomberg continues to do on APR. The Bloomberg team have also formed extended academic networks with APR researchers in UCL that would have been unlikely without this project. Many of the tangible Fixie outcomes delivered so far are in the form of new knowledge about how human developers should be considered to enable successful APR tool development. This new knowledge has been published in two papers in the top journal venue of IEEE Transactions of Software Engineering. We hope that these papers will gain traction in the academic community as a foundation that researchers of new APR techniques will use to guide them in developing more usable and acceptable APR tools. Currently the citations to this very groundbreaking human work are disappointing, demonstrating how difficult it is to get human factors in software engineering to be taken seriously. This problem is despite many companies reporting that their difficulties are human rather than technical. |
First Year Of Impact | 2021 |
Sector | Digital/Communication/Information Technologies (including Software) |
Impact Types | Economic |
Title | Fixie APR Tool |
Description | A tool that offers developers fixes to bugs in Java code. The approach is based on using GI to generate potential fixes that reduce the predicted defective score of a piece of code. There are two elements to this tool - one from an academic perspective to progress the difficulty of bugs that can be fixed. And another element developed in collaboration with Bloomberg that fixes many minor bugs as quickly as possible. |
Type Of Material | Improvements to research infrastructure |
Year Produced | 2022 |
Provided To Others? | Yes |
Impact | The Bloomberg collaborated element of the Fixie tool is getting significant traction from the two high visibility papers that we have published. These are both attracting citations. The Bloomberg devs involved in the work are also being invited to other institutions to discuss the work done. Additional collaborations have also branched out from this work, most notably with the CREST group at UCL. |
Description | Fixie Twitter |
Form Of Engagement Activity | Engagement focused website, blog or social media channel |
Part Of Official Scheme? | No |
Geographic Reach | International |
Primary Audience | Professional Practitioners |
Results and Impact | We constructed a Fixie project Twitter sight. We tweeted about project outcomes to our 400+ followers. This Twitter site was maintained by one of the project researchers. The Twitter site is: @the_fixie |
Year(s) Of Engagement Activity | 2020,2022 |
Description | Fixie YouTube Channel |
Form Of Engagement Activity | Engagement focused website, blog or social media channel |
Part Of Official Scheme? | No |
Geographic Reach | International |
Primary Audience | Professional Practitioners |
Results and Impact | We developed a YouTube channel with a series of online training videos explaining a variety of aspects of Automatic Programme Repair. These videos explained our tools and techniques as well as the use cases of these primarily for software practitioners, but available for anyone to view via YouTube. We publicised our YouTube channel via of Twitter pages (for the Fixie Project and for our SE research groups). |
Year(s) Of Engagement Activity | 2022 |
URL | https://www.youtube.com/watch?v=zJpap6U2yv4 |
Description | On-going relationship with Bloomberg |
Form Of Engagement Activity | A formal working group, expert panel or dialogue |
Part Of Official Scheme? | No |
Geographic Reach | International |
Primary Audience | Industry/Business |
Results and Impact | On going regular meetings/engagements with industrial users of the technology being developed by the project by two of the project's PDRAs. |
Year(s) Of Engagement Activity | 2021,2023 |