Saturday, May 6, 2017

Releases per bug



Traditional teams count "# of active bugs" and "# of bugs fixed per week" and the like. These drive the wrong behaviors, rewarding create/find/fix over eliminating the underlying causes of bugs.

As the bug injection rate approaches zero, you can shift how you work and how you think about bugs. A few metrics that I like for BugsZero teams:

  • # of releases since the last bug
  • # of user stories completed since the last bug
  • # of user stories shipped since the last bug

Slightly better every day

If you have legacy code, you should strive to make things slightly better every day. (Sometimes referred to as the scout rule).

There's a lot of nuance in here that is important to understand.

Things

Only improve what matters for the work you're doing today. 

- Reading. If you need to read some code, record your understanding of that code by renaming something or extracting a method.

- Writing. If you need to change some code, refactor it to make the change you're doing a little easier and safer.

- Not changing. If the right place for this change is in module A, but you know better than to touch A because it's so incredibly terrible, so instead you hack the change in to module B: go refactor a little bit in A so that maybe in the future you can put the next change where it belongs.

- Tools. Anything that affects your ability to get work done is potentially in scope. For example, if you find yourself waiting for the build a lot, then do something to optimize the build.

Slightly

You find the code you need to work in. It's a mess. You know how you would like it to work. You've been itching to rewrite it for a while, and then it would be pretty good and not suck.

Don't.

Making it all the way good would take too long. You need to get your work done. And there are other parts of the system that need attention, too - focusing on this could would mean leaving that other code in a bad state.

Make it only slightly better now. Trust that if you need to touch it again tomorrow, that's when you'll make it slightly better again. 

Better

Extracting a method can make code better. But the feature or bug fix you're putting in will make things worse. To actually leave the code better than you found it, you must make more improvement than you degrade it. 

Code quality is difficult to measure, but we can measure things like cyclomatic complexity and lines of code and build/test/deploy duration, and I do mean that these should improve over time, even as the system gains more capabilities and delivers more business value. 

Every day

There are exceptions. Maybe you need to get this bug fix done in a hurry, and can't see a quick, safe way to improve the code. But most of the time, things are better at the end of the day than at the beginning. And there will be days when things are on fire; but most of the time, things are better at the end of the week than at the beginning.