XP Feedback Loop Suggestion
Extreme Programming, developed and evolved by Kent Beck, Ron Jeffries, Ward Cunningham, Don Wells, and others, is an incredible software development methodology. It helps build high-quality software that is adaptable to changing requirements. The feedback loop introduced by Extreme Programming ensures having multiple verification mechanisms for the code. This blog intends to make a few updates to the existing feedback loop.
- Author:
- Siddhesh Nikude, Director / Software Craftsperson at Nelkinda Software Craft
- Reviewer:
- Christian Hujer, Director / Software Craftsperson at Nelkinda Software Craft
- First Published:
- by
Nelkinda Software Craft Private Limited - Last Modified:
- by Siddhesh Nikude
- Approximate reading time:
1 Feedback loop in Extreme Programming
The figure above talks about the loops for Extreme Programming. Even though the image is from 2001 by Don Wells, everything from this is still relevant in the software world. But there has been quite an improvement in the past years, ranging from computing power to tools and technologies. It has enabled us to update the above diagram in terms of number of loops.
2 New Feedback Loops
The new loops are explained below
2.1 IDE / Code Analysis IDE Plugins
The IDEs are getting smarter. They already point out improvements or warnings as the code is being typed, making it one of the fastest feedback loops. The feedback time is in seconds (or less) The solution is provided for a lot of issues. Code analysis plugins like SonarLint, PMD, Checkstyle are available as IDE plugins, further reducing the feedback time.
2.2 Build / Code Analysis Build Plugins
The code analysis IDE plugins discussed above can integrate with the build tools like Maven and Gradle. If configured, they act as a quality gate. If plugins observe an issue in the code, the build fails. The advantage, in this case, is uniformity across the team. The IDE plugins can be available depending on what IDE is being used. The developers should have the autonomy to use the IDE of their choice. But the build tool is the same across the team, and has no dependency on the IDE. If the lower levels of a common coding standard can be agreed on and enforced automatically, the conversations and evolution of a common coding standard in a team can focus on the more important higher levels of design. So code analysis plugins can use the same configuration across the team to ensure uniform coding standards. The feedback time depends on the build time. Ideally, the build time should be in minutes.
2.3 Continuous Integration / Pipeline
Continuous integration is the practice of integrating the code frequently. In a Typical high-performing XP team, integration should happen every few hours or more often The shorter the period of integration, the quicker the feedback for the integrated code. Tools like Jenkins, Circle CI, and GitLab can be used for running a continuous integration server (also called as Pipeline). The pipeline should take few hours or less to execute.