why_shouldn_t_we_set_up_dedicated_defect_teams
Differences
This shows you the differences between two versions of the page.
Previous revision | |||
— | why_shouldn_t_we_set_up_dedicated_defect_teams [2020/06/04 11:20] (current) – Removed LINKBACK hans | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== Why Shouldn' | ||
+ | |||
+ | > Or "What are the benefits of having value production teams work on defects?" | ||
+ | |||
+ | Came across [[http:// | ||
+ | |||
+ | Starting with the idea that development has the following characteristics: | ||
+ | |||
+ | * Programming is not typing; it is a purely intellectual labor | ||
+ | * Code is a collection of decisions, not a collection of keystrokes. | ||
+ | * Good code is a set of decisions made well. | ||
+ | * A defect is a result of one or more decision(s) made poorly. | ||
+ | * Maintainability is the ability to arrive at good decisions quickly | ||
+ | * Poor code invites or limits decision-makers to compromised decision-making | ||
+ | |||
+ | It then takes you through the idea that if these are true, then have a team become expert on bug fixing actually won't help the problem, because the non-bug team is still producing all the bugs. We say this with the statement "we want the team to feel the pain of the bugs they produce" | ||
+ | |||
+ | But that doesn' | ||
+ | |||
+ | The big thing that the article points out, and the point of this discussion, is that to deal with the root cause, we need to say more than "teams deal with the pain". We have to encourage and help people on teams understand that they might want to do work so there is less pain in the future. The article talks teams working to ensure that bugs are not only addressed but that we increasingly create systems that reduce the chance of a defect getting into the work we do. The article calls this a team's " | ||
+ | |||
+ | There may still be reasons we create a bug team to help deal with a capacity issue. But it is also important to understand that setting up a bug team won't necessarily improve the quality of the code produced. Irrespective of whether there is a team in place to do this, we still need to deal with the root cause issue, and really focus on understanding why we have defects. We need to set up our development environment so that we get feedback very quickly about the bugs, and then encourage real analysis back to the coding that was done to understand how we can stop bugs from entering the system the same way. This is the only approach that has the potential to reduce the capacity that we allocate to working bugs freeing everyone up for doing more interesting, | ||
+ | |||
+ | {{tag> | ||
+ | |||