Sorry, but this is not valid. I can't leave this uncommented.
Assume the article is right, then all metrics would be bad. Thus we can't find any example that contradicts the statement in the article.
If we pick coverage of automated tests as a metric, then _more_ test coverage would be bad given the article pretense. Clearly there can be bad tests, like any code, but assume the tests are valid, would increasing the coverage be bad as such? Clearly no.
Pick another example, like cyclomatic complexity. Assume some code controls what or how we measure cc. If we change this code so _more_ code is covered by CC-measurements, then this would be bad given the articles pretense. Again clearly no.
Yet another one, code duplication. Assume some code measure code bloat by a simple duplication test. Testing more code for code bloat would then be bad, given the article pretense. Would all code duplication be bad? Not if you must keep speed up in tight loops. So perhaps you may say a metric for code duplication could be wrong sometimes.
Measuring code quality is completely valid, as is measuring article quality. The former is disputed, but the later is accepted as a GoodThing™ by the same programmers. Slightly rewritten; "Don't count me, I'll count you!"
On Thu, Mar 21, 2019 at 7:07 AM Gergo Tisza gtisza@wikimedia.org wrote:
On Wed, Mar 20, 2019 at 2:08 PM Pine W wiki.pine@gmail.com wrote:
:) Structured data exists regarding many other subjects such as books and magazines. I would think that a similar approach could be taken to technical debt. I realize that development tasks have properties and interactions that change over time, but I think that having a better quantitative understanding of the backlog would be good and would likely improve the quality of planning and resourcing decisions.
Focusing on metrics is something bad managers tend to do when they don't have the skills or knowledge to determine the actual value of the work. It's a famous anti-pattern. I'll refer you to the classic Spolsky article: https://www.joelonsoftware.com/2002/07/15/20020715/ _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l