Where should feedback loops be built into the development life cycle? What’s the right cadence for developers to get direct feedback on their code?
Sort By:
Oldest
VP of Information Security in Software20 days ago
My suggestion is narrowly focused on vulnerability and software quality management and left shifting problem discovery and remediation through just-in-time feedback. Having developers use code and software composition/component analysis plug-ins in their IDEs is a great way of delivering immediate, interactive feedback. The plug-ins identify problems right when they are introduced and suggest ways to eliminate those. This is the least expensive place to catch and remediate those types of problems. Director of IT in Media20 days ago
The feedback loop can be implemented at the IDE level to share the feedback on the developing code during compile/runtime. However, an additional gateway could be at the code repository level when the particular feature or the pull request is raised. Director of Engineering19 days ago
It is very difficult to give a definitive answer to this, as I feel the answer is a function of a number of factors: Requirements volatility, project scale, Developer domain knowledge/ experience, delivery style (agile/ waterfall), requirement and validation lifecycle control etc. It also depends on whether we are talking directional feedback or validation feedback? If we assume a modular/ agile approach on a medium scale programme with relatively stable requirements where the developer has some previous exposure to the domain and the use of DevOps or similar: the directional feedback should be relatively short cycle but light touch, as it is more about ensuring consistent understanding of the requirement than assessing the code/ solution. So short cycle feedback on semantic and functional consistency is key, which then give the developer the free reign to code as they see fit (giving room for creativity) to that end. The validation feedback will then be less frequent due to the lower risk of divergence and more aligned to capability delivery milestone assurance. Where this tends to go wrong is people trying to to short cycle validation or doing the longer cycle validation without the short cycle lightweight directional feedback. CISO in Software19 days ago
Read Gene Kim's "The Phoenix Project" to really understand the big picture here. It's a quick fun read. You'll learn that before you focus on feedback loops, the first step is to get the work flowing by breaking it into small pieces.
In general, we want to have as many tests as close to the code level as possible. These tests should run quickly in the pipeline to provide immediate feedback, ideally every time code is committed or at least when a pull request is made. Quick feedback helps identify if anything is broken early in the process.
It’s also important to take a hard look at the tests you have and make sure that they’re providing value (not just inflating code coverage metrics). Unnecessary tests should be eliminated. Longer performance tests could also run overnight on a development branch to avoid blocking developers from checking in code and maintaining automated releases.
Beyond code and technical feedback, business feedback is also essential. Developers should have opportunities to demo their work to business analysts or quality engineers before completing a product feature. Getting early feedback ensures that the development work aligns with business expectations, especially for UI-based features.