# Feedback Loops * With feedback, we learn what went wrong, and make appropriate changes * We all make mistakes, false assumptions, and we need ways to catch this early on * Examples places to seek feedback * Because our product managers don’t know what they want, they find out from the customers. But customers get things wrong * Because our product managers don’t know everything about systems, they invite other experts to become stakeholders in the project. Stakeholders can be wrong * Because developers don’t know what to code, they find out from the product managers. What is coded can be wrong * Mistakes made during code occur, the IDE will pick these up, not all of them * Because developers make mistakes in understanding the existing code, developers use a statically typed language. The compiler corrects developer when they are wrong. * Because developers make mistakes while thinking, they work with a pair. The pair corrects their pair * The same is true for code reviews on pull requests * Because both pairs are human and also makes mistakes, they write unit tests. The unit tests correct the pair when wrong. * Because there is a team that is also coding, code is integrated with other code. The code won’t compile or test's pass if wrong * Because the team makes mistakes, acceptance tests are written that exercise the whole system. Acceptance tests fail then wrong * Running acceptance tests is not manual process as this can be forgotten to be triggered. Instead the build will automatically run the tests * Because we didn’t think of every scenario, we get testers to explore the system. Testers will tell us if it’s wrong * Because we only made it work on one person's laptop, we deploy the system to a realistic environment. The tests will tell us if it’s wrong. * Because we sometimes misunderstand our product manager and other stakeholders, we showcase the system. Our stakeholders will tell us if we’re wrong. * Because our product manager sometimes misunderstands the people that want the system, we put the system in production. The people who want it tell us if we’re wrong * Because people notice things going wrong more than things going right, we don’t just rely on opinions. We use analytics and data. The data will tell us if we’re wrong * Because the market keeps changing, even if we were right before, eventually we’ll be wrong. Use data, to find this out * Because it costs money to get it wrong, we do all these things as often as we can. That way we are only ever a little bit wrong. * Don’t worry about getting it right. Worry about how you’ll know it’s wrong, and how easy it will be to fix when you find out. Because it’s probably wrong ## Risk * Frequent releases reduce risk * Risk is a factor of the likelihood of a failure happening combined with the worst-case impact of that failure * Risk = Likelihood of failure × Worst-case impact of failure * an extremely low-risk activity is when failure is incredibly unlikely to happen and the impact of the failure is negligible * High-risk activities are when both sides of the product are high—a high likelihood of failure and high impact. * Large, Infrequent Releases Are Riskier * Risks include * outage * data loss * Solution of testing everything is impossible * We can test for the known scenarios, but we can’t test for scenarios we don’t know about until they are encountered (the “unknown unknowns”). * No matter how much you test, production is the only place where success counts --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://hanfak.gitbook.io/workspace/management-workflow/feedback.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.