Most people see bugs as a fact of life in software development. Just like city-wide fires used to be taken as a fact of life in urban living. The key to no longer burning cities to the ground was fire prevention, not improved fire fighting. I've applied similar thinking with dozens of teams and shifted to a world in which bugs occur at the same frequency as city-wide fires.
Let's imagine this world for a moment. These teams don't have:
- a bug database. They just use a section of the whiteboard.
- lots of testers.
- large suites of automated tests. Lots of their code is untested and known bug-free (yes, that is possible).
- bug triage meetings.
- large customer support teams or devs handling escalations.
- problems in operations or large ops teams.
- story "done-done" criteria or delays in shipping.
- complex trade-offs in prioritizing stories against each other.
- lost revenue due to market embarrassment.
It turns out that most software development activities arise from one source: bugs. They are failure demand, and thus 100% waste. Teams that stop writing bugs get to stop doing these rituals. They spend a lot more time on value delivery and reduce costs across the organization.
In this talk, I'll show how these teams have stopped writing bugs. We'll discuss the source of bugs and I'll show you how to code differently so that bugs just...don't happen.
Outline/structure of the Session
Mostly conversation with live coding.
- Understand the fundamental source of all bugs (complexity) and identify it precisely.
- Code differently to take into account the way the human mind works.
- Safely change code without introducing or accidentally fixing bugs, without requiring testing to prove that.
- Apply individual techniques to reduce the number of bugs you personally write.
- Apply team techniques to reduce the number of bugs you collectively write.
Development teams and managers