Since feedback is a form of communication, excessive feedback will have the effect like an explosion in communication paths and will eventually produce more noise than signal.
Any feedback loop in the system must help facilitate the management of change and efficiently adapt requirements along the the way. If this is not the case for a feedbackloop, folks will try to avoid it.
As developers we also experience a decrease in quality and value of feedback if it is not immediate enough and/or requires too much effort from a team member to receive it. So most of the feedbackloops are built right into modern software development. Take a look at the following list of areas where a software development team or team member receives feedback in different forms:
- Your IDE checks syntax and indicates errors before you hit ‘save’.
- A release demo for your customer generates prose user feedback.
- Commit hooks refuse your changes.
- Deployment on development and staging systems works or doesn’t.
- The Compiler compiles or refuses to compile and returns errors.
- Daily standup meetings serve as publishing institution of individual statuses, schedules and problems. Team members get updated, help each other out or problems get escalated up the command chain.
- Pair programming for direct feedback from colleagues on development skills, technical decisions, used tools etc.
- Sprint reviews reflect development processes, collect team feedback and improve them.
- Test driven development repeatedly asserts requirements and APIs of existing and future components and their interdependencies.
- The continuous integration server runs all test suites, generates documentation, runs the build, code sniffer etc. and informs the whole development team if something goes wrong.
I hope this article serves you as a short reminder for where and how feedback can create value in your software projects. And remember: Software is written by humans and feedback is the opposite of thought-reading, which often leads to unnecessary friction and pain.