From Pair Programming To Code Review: 7 Feedback Loops You Should Try Using
Working in software development requires that we find the right techniques to achieve quality and customer satisfaction. Learning about development and flow techniques from experienced peers can be helpful. But if the team has a lack of senior peers or insufficient commitment, we may have to find alternative routes.
While studying how to improve my methods, I watched an interesting video wherein Noel Ford explained how useful feedback loops are in software development. Working from that premise, I started collecting and applying the best practices that could most help developers deliver software that meets customer expectations while also improving code quality.
First of all, let’s define a feedback loop. According to Wikipedia, “Feedback occurs when outputs of a system are ‘fed back’ as inputs as part of a chain of cause and effect that forms a circuit or loop. Any Agile or Lean framework incorporates this concept, but I think the closest implementation of feedback loop is defined inside kaizen with the PDCA cycle.
The PDCA Cycle
PDCA stands for “plan-do-check-act” and in kaizen is a technique used for continuous improvement of a company’s standards. The team tries first to analyse a problem, retrieve the metrics in the current situation, define a strategy for improvement toward achieving the intended result, and finally retrieve the metrics of the process to assess whether improvement really occurred so the team can adapt strategy to obtain better results and create a new standard.
This is a continuous process that should be carried out several times to aim for the best possible results:
TDD, BDD and Unit Testing
Test-driven development, behavior-driven development, or simple unit testing is the first feedback loop that should be established on any project.
These are helpful for the healthiness of your project not only because helps you to better define the requirements, design better APIs, and obviously check the sanity of what you’ve written or refactored but also because testing gives you feedback on your work in seconds – and you can have this feedback every time you save a code file or when you push the code in your version control system.
Often we avoid proper static analysis in the belief that we lack the time to define what we need to analyze, but it doesn’t really take a huge effort to establish a good strategy, and the potential benefits are important.
Static analysis can help you immediately recognise areas in your software that could be simplified or improved without deep-diving inside the code. It supplies a powerful feedback loop that in seconds or minutes can provide metrics to analyse during the whole development life cycle.
One of my favorite metrics techniques is cyclomatic complexity. Applying this metric during the whole life of your software will help you understand the healthiness of your project and what areas need attention.
Code coverage is another useful metric, as it can suggest the extent to which your system is covered by tests. Unfortunately, though, it doesn’t give you feedback on the test quality.
Code review definitely improves project quality and normally should be performed every time a developer in the team makes a pull request directly inside the version control system. Unfortunately, they are often skipped or, worse, ignored because we trust our peers too much or don’t have time. But if applied properly this technique can improve the code quality and architecture of your software to an amazing degree.
Usually it takes days, not seconds or minutes, so bear in mind that with this technique your developers don’t have the kind of frequent feedback afforded by the previously described techniques.
Several books describe and discuss this topic; I suggest scheduling one or more sessions at the beginning of any project to architect enough of your software that you can start development and review the design and implementations iteration by iteration (possibly with every sprint).
You’ll see a constant improvement in your code without a huge up-front effort, meaning less need to accommodate changes for future business requests and more likelihood that your architecture and design decisions will faithfully reflect the project specifications. Usually these feedback loops are the only ones that maintain overall code structure and architecture sanity as viewed with an “eagle eye.”
This ceremony, used not only by Scrum teams but in many Kanban implementations, primarily provides an opportunity to synchronize team member efforts as well as a starting point for discussing potential improvements. As the name suggests, it’s a daily activity whose value hinges on not only on the technical aspects but also team communication and the big picture behind the project.
These aspects are fundamental, because often developers are so focused on details they miss the perspective that could keep them from spending unnecessary work or time on secondary features (remember the Pareto principle).
An Agile retrospective, if well organised, is the most effective ceremony inside the Scrum framework to produce feedback that really helps improve projects and promote healthy teams. I facilitated several retrospectives and I’ve always gained a lot from them; if you can create a good atmosphere, defining properly what you want to achieve, you may reap surprisingly good results.
For this purpose, the retrospective is organised at the end of each iteration (usually every two weeks), but I really suggest more often if the team is recently defined or has more than one new member, to help newcomers feel part of the team and acquire its mind-set and to permit review of the resulting team performance as a whole.
Feedback loops help on a daily basis with project improvement and delivery success; more feedback loops mean greater control of software quality and better customer satisfaction, exactly the goals you are trying to achieve every day. Don’t be afraid to try new techniques to improve your team and your company. Fail fast, retrieve metrics, and learn from them; the worst that can happen is that you really improve!
If you're looking for your next job as a software engineer, have companies apply to you by adding your profile to Snap.hr.