Add a metric for "Improve quality" in introducing-metrics-in-innersource

[guilhermebrasil]

Regarding code quality improvement, the rework rate captures several software engineering elements. It helps to observe the practical effects of increased code quality, allowing teams to spend most of their time on items that add value to the end users.

[spier]

Makes sense to me.
Will be merging this shortly.

Out of curiosity:

• what qualifies as 'rework'?
• how can you measure the 'rework rate'?

Also if you know of any online resources related to this, I would be interested in reading more about it.

[spier]

@guilhermebrasil I just merged PR #455, which also changed this pattern.
This seems to lead to a merge conflict.

The GitHub UI does not let me resolve the merge conflict here.
Could you please pull the latest from main and resolve the merge conflict on your branch, and then push again?

[guilhermebrasil]

@guilhermebrasil I just merged PR #455, which also changed this pattern. This seems to lead to a merge conflict.

The GitHub UI does not let me resolve the merge conflict here. Could you please pull the latest from main and resolve the merge conflict on your branch, and then push again?

OK @spier , I did solve the conflict.

[guilhermebrasil]

• what qualifies as 'rework'?
• how can you measure the 'rework rate'?

what qualifies as 'rework'?

I like the following definition:

"Rework in software development is the additional effort of redoing a process or activity that was incorrectly implemented in the first instance or due to changes in requirements from clients. It usually results from errors, omissions, failures, changes, poor communications and poor coordination."

Reference: https://airccse.org/journal/ijsea/papers/6515ijsea02.pdf

how can you measure the 'rework rate'?

I am using the % of the time (touch time) a squad spent on correction artifacts in relation to the total development effort (total touch time on all stories/corrections).

[spier]

@dicortazar @NewMexicoKid @rrrutledge what do you think about adding an appendix to this pattern that explains the different metric candidates a bit more, as not all of them are self-explanatory?

The explanations could look similar to what @guilhermebrasil did in the last comment above, including links to references where people can learn more about the metric.

Also if you know of any companies applying this pattern, it would be great to see a PR to push this pattern to the next level ;)

[lenucksi]

@dicortazar @NewMexicoKid @rrrutledge what do you think about adding an appendix to this pattern that explains the different metric candidates a bit more, as not all of them are self-explanatory?

The explanations could look similar to what @guilhermebrasil did in the last comment above, including links to references where people can learn more about the metric.

Also if you know of any companies applying this pattern, it would be great to see a PR to push this pattern to the next level ;)

Not any of the above, but a metric that is not properly defined yields anecdotal evidence at best. So yes to annex for exactly that. I really like that @guilhermebrasil referenced a proper paper for his rework metric. We need more proper papers tied to in the patterns.