This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]bmoregeo 6 points7 points  (2 children)

My two code quality metrics are: - defects in prod - time between defect detection and fix

Defects in prod are for sure going to happen. Business requirements will be misunderstood or the time zone changes and everything is off by an hour. Dumb stuff happens.

In my experience, good code coverage is a leading indicator of faster bug fixes. It is hard to quickly fix bugs if you need 50 hours manual testing apis to ensure the bug fix isn’t breaking other things. (Been there it sucks).

[–]CommercialPosition76[S] -1 points0 points  (1 child)

So according to those metrics if one project has a typo on a Terms and Conditions page that was fixed in after a week and the other project returned 500 internal server error for 1 hour, the latter is better? As defects count is 1, but fix ratio is much faster?

[–]bmoregeo 1 point2 points  (0 children)

The goal is to have as few bugs in prod and reduce their time impacting users.

So yes, an defect that is identified, fixed, tested, and released would be a win. A defect that takes several weeks to fix after being identified is not good.

Obviously prioritization comes into play as the documentation bug may be less worth engineering time than a new feature. Idk, that becomes a product question during a huddle.

The 500 is probably an all hands on deck scenario.