While bugs hurt your entire organization, they hurt each part of the organization differently. We have a variety of Change Series to address different aspects of bugs depending on what the team is facing.
- Prevention of bug categories
- Hazard Thinking for when it’s not known what design or environmental factors lead to creating bugs
- Testing Untestable Code once main bugs sources are addressed and it’s time to focus on communicating between developers
Change Series: Prevent Code Misunderstanding Bugs
Difficult-to-understand code is the #1 leading reason that developers write bugs. This change series prevents those bugs by making code easy to understand without making stories take longer.
Organization ROI: Decrease time spent finding, triaging, and fixing bugs by not writing them in the first place.
Engineer ROI: Code becomes obvious, so you don’t need to worry as much while editing it. Be less careful and more successful.
Change Series: Prevent Duplication Bugs
Duplicated code is one of the leading reasons that developers write bugs. This change series prevents those bugs by fixing the existing duplication without making stories take longer.
Change Series: Prevent Non-local Interaction Bugs
Non-local interactions cause few bugs, but those bugs are particularly hard to find and fix. This change series prevents those bugs by eliminating existing non-local interactions without making stories take longer.
Change Series: Hazard Thinking
Each team creates bugs for different reasons. Learn what Hazards cause your team to create bugs and how to prevent them long before unit testing. Learn which Prevention Change Series to take, and what to do for the 10% of bugs that have causes unique to your team.
Change Series: Test Untestable Code
This change series allows you to make untestable code become easy to test. This will not prevent any bugs, but it will speed up release validation, find bugs earlier, and reduce the cost of sharing code between teams.
