[ ] Days since last bug... 12 months.
[ ] Bugs written... Get to the point where it's none.
[ ] 6 team case study. 3days to 3weeks.
[ ] Environment changes count as bugs.
[ ] If a service goes down and your software fails, that's a bug.
[ ] This is not about narrowing the definition of bug until you have none.
[ ] TDD
[ ] BDD
[ ] Cause bugs: Punish mistakes, Large code, many lines per method, many classes,etc. Schedule pressure, quality vs. speed, work overtime, hard to read code, poor names, large project size, cyclomatic complexity, nested control structures, task switching, unexamined assumption, incorrect mental model, Early optimization, too much context for the brain.
[ ] Prevent bugs: Continuous integration, pair, visualize clear design, strong unit test culture, understand mistakes, reward learning, good white space, Limit complexity,
[ ] Root cause analysis.
[ ] Don't build up technical debt.
[ ] Brain has no alert system when stuff is jettisoned.
[ ] Extract method reduces complexity.
[ ] Avoid misleading names.
[ ] Basically everything is a data transformation.
[ ] What are the sources of bugs in the human brain?
[ ] Express intent with unit tests.
[ ] Use the words from requirements in your test names.
[ ] Feedback about whether there's too much load on the brain can come from tests.
[ ] Good design: Is this easy to test? Is this easy to name?
[ ] Iteration. Legacy code- how do you know when you can commit? New tests, moving away from being legacy.
[ ] In legacy, good is impossible. Better in one way and worse in none. Check it in. Only goal.
[ ] Amazon. Refactoring and expressive tests.
[ ] Must be less than 10000 lines.
[ ] Amazon marketplace. Publish there. Services. Evaluations.
[ ] Leads to code reuse.
[ ] Code is small, legible, verified, operationalized.
Thursday, February 4, 2016