Feedback Loops in the Real World
In Agile, feedback is essential for everything. Whether you are writing code, iterating through a Sprint, making a car, or planning your vacation, feedback is key. The response and how quickly you receive that response is critical to reducing “idle time”, which can encourage misconceptions (like “It compiles on my machine so the code is good”) or bad behaviors (like allowing the build to stay red, allowing tests that fail occasionally to remain, or lobbing build grenades). To demonstrate, let’s consider three different real-world response feedback loops involving electrical switches: a light switch, a doorbell, and a pedestrian street crossing button.
- Light Switch: The basic light switch is a simple electrical switch that we encounter every day. Flip the switch and the light immediately comes on unless the light is burnt out. Feedback is immediate.
- Doorbell: A doorbell, again, is a simple electrical switch. Most people only press it once. If you don’t hear the bell—the feedback—you might consider pressing it again. I wait at least 10-30 seconds to see or hear if someone is coming. After that, depending on if I heard the bell or not, I’ll either press the doorbell again or knock. Generally I’ll wait less time—perhaps 5-15 second—to either try the doorbell a third and final time, knock (which I always do), or leave. People generally don’t knock or press the doorbell continually because at some time in their life they got some strong negative feedback not to do that.
- Pedestrian Crossing Button: Now consider a pedestrian crossing button, which is a slightly more complex electrical switch. Think about how you and/or others interact with that switch. I know that I find it very difficult to press this button just once, although I flip a light switch just once. It is not uncommon to see people mashing, pounding, and even kicking on those buttons multiple times.
Why Do We Exhibit Such Different Behavior for These Three Switches?
Feedback delays! Light switches give us immediate feedback while the other two have delayed feedback with the greatest delay being the crossing button. It can take a long time for some stop lights to change and doubt has time to fester. You push the crosswalk button and nothing happens, so you doubt yourself: maybe you didn’t press the button or you didn’t press it hard enough. So you press it until the light changes! (Note there are some new crossing buttons that give audio and visual feedback when they have been pressed. I see people only pressing these once.) The faster and more “noticeable” the feedback, the less chance for doubt, bad habits, and other non-productive behavior to happen.
How Does That Relate to Software?
In a recent meeting with a major Washington company, a group of mid-level managers was trying to figure out why the deployment guy Joe (not his real name) was swamped with work. A quick investigation revealed that whenever one of seven environments went down on a code deploy for the group—which consisted of 40+ developers—everyone always went to Joe expecting him to fix the integration and deployment issues/defects, never taking into consideration that Joe had all his other normal duties to tend to as well. This group had minimal unit test coverage, relied on gated check-ins (only sparse unit test coverage and a heavy reliance on code compilation) as the only feedback on code quality and stability. Deployments to the various staging environments were in the process of being automated but there was still a lot of manual configuration and tweaking by individuals. For example, there was no immediate automated feedback on code check-in for environment stability (deploy or system/functional testing) or regression. There was no reliable automated system for deploying to intermediate or production environments. The quality feedback was generated only by a “deploy” that happened days after code check-in and fell on Joe’s shoulders. The effect was so delayed that it couldn’t easily be linked directly to the initial cause—much like the button at the pedestrian crossing.
Because the feedback was so delayed, it gave the developers at this company the illusion that there was no negative feedback for the code they checked in a month or two ago and, therefore, the code must be good. Because they thought their code was code, they continued to create code under all the same assumptions, never connecting the negative feedback with their own buggy code. This resulted in a vicious cycle that resulted in Joe being overworked.
When the company told me about this problem, I advised them to shorten their feedback loops, modify the build scripts to create a build environment, deploy the code, implement some minimal functionality and regression tests and run them on EVERY check in. In such an environment, before the build can go green, you get instantly useful feedback that the code is fully functional . Thus the developers know they broke the system a lot sooner, which leads to improved code quality, which means fewer integration or deployment issues/defects for Joe to fix, which means Joe keeps his sanity! Now that is virtuous cycle worth maintaining.
My Advice to You
…is the same:
- Shorten your feedback loops and improve your productivity, because delayed feedback is essentially ineffective feedback.
- Know your tests are failing, fast.
- Know that your process improvements either work or don’t work, fast!
- Promote a culture of high visibility and quick feedback with little to no delays.
- Along with shortening your feedback loops, having multiple feedback loops can give you data to improve upon too.
Agile and its many varied ceremonies afford many opportunities for overlapping and, in some cases, recursive feedback loops. The light introduced by doing these things can foster good behaviors that lead to higher-code quality and grant your project time, because it’s easier to fix mistakes/defects sooner rather than later.