Code Health Group/projects/Code Health Metrics/meeting notes/20180911

Code Health Metrics Working Group - 20180911

Attendees: Guillaume, Piotr, Željko, JR

Intros (if people don't already know each other)

Key Points:

everyone on this team is very interested in improving Code Health and measuring the progress being made.

Background

Zeljko: What is the relationship between the Code Health Group and this group?

*JR: (enter long-winded response here) TLDR; This work group is focused on a finite project. We've come together to address a specific topic and will disband once we do so. The Code Health Group is a perpetual group of stakeholders that help steer and support projects/work groups like this one.

Key Points:

Code Health topic came as a result of some initial discussions that JR had when he first started. The pain points and generally feedback that was collected tended to point to concerns around Code Health.

Purpose

Guillaume: Why do we care about code health -> Cost of change. Only collect/report metrics on new code changes, not unchanging code. What we care about is the improvement of our development processes, not the code itself.

Zeljko: The infrastructure to collect the metrics / logging would be available across all the code as well.

Piotr: Another Code Health area that is important is maintainability (or operatability). How the system/code is perfoming in production (like logging, etc...).

Key Points:

Although we are talking about Code Health, what we are truly seeking to improve is our processes. Improved code health will come as a result of that.
Focusing our metrics and analysis on code that is changing will ensure that we work on what matters most. It's not a valuable use of our time to measure and improve code that isn't being changed and works in it's current state.
We need to include operational/maintenance areas in Code Health.

Questions/Thoughts:

JR:Although the focus is on measuring things that we are actively changing, there is the question of Code Health playing a role in people deciding what to work on. For JR:example, some extensions or even areas of Core that have low Code Health may be actively avoided, resulting in people creating new extensions as an avoidance tactic.
JR:Some may still want a baseline of where we are at across the code base. This shouldn't be a problem because any solution that we devise should be repo agnostic. Code Health may at some point become a factor considered when prioritizing refactoring work.
Kunal: Gamification/leaderboards/etc. really does work. Handing people a chart showing their code is only 85% good (and giving detailed information on how to fix it!) is a pretty good way to get people to fix the issues :)
- JR: I've been thinking about Gamification in a broader sense as of late too (Badges, etc...). We should talk more about this. A little outside the scope of the metrics definition and implementation, I've been working on developing a Code Health "newsletter" to go out once a month. Included will be metrics and such, but I thought it would be worth looking into coming up with a badge system for code health. I plan to bring this up next week during the Code Health Group meeting.

Scope/Duration

Piotr: Measurement could be a blocking event in Gerrit or simply a warning. Warnings though would likely get ignored. Blocking may be the only way to get people to pay attention and address the issues.

* JR: At Google, they took the approach that early on they worked with supporters and early adopters that were happy to participate and would take action on the information they were provided. As time went on, things did become blocking mostly to encourage the laggards to participate as well. One thing that JR was thinking of doing was a montly Code Health update that would acknowledge the progress that was made. Encouraging others to do so through positive reinforcement.

** Kunal: Agreed with both. Start out with some people who are interested in deploying new tools, get them to beta test, and then roll it out everywhere. Definitely has to be blocking to get people to pay attention.

Guillaume: Although we could talk about metrics (something that I love to do), we could also select 1 or 2 metrics to focus on through implementation. We can then decide if we continue to interate as a team or disband and hand it off to a different group.

* JR: I like this idea. It will help us better understand the full lifecycle and what it takes to define, implement, and report on aspects of Code Health.

** Kunal: I like it too. It's too easy to fall in the trap of "look at this pretty graph, you need to improve xyz!" when often the metric itself is questionable or has bugs and needs further tweaking.

Key Points:

Instead of working on defining the base set of metrics all at once and them implementing them in a later phase, we discussed taking one or two metrics and going through the entire define-implement-collect lifecyle. We can then iterate over additional metrics. Although there are some Code Health quartlery/annual goals, JR is okay with altering them to reflect what we've decided is the best way to approach the metrics work.
The Reading group is ramping up on some significant refactoring projects and would be a great test bed for our early efforts. Other candidates are the platform and search platform refactoring efforts.

Meeting and other group logistics

We will meet weekly for the next week or two to refine the scope of work that we are pursuing in this first phase. After that we will focus on async work, meeting to sync up as needed.

Next Steps

select area that we want to focus on (1 or 2 metrics)
define the fifth area of Code Health (maintainability/operationability)
[added]review exiting metrics and attempted metrics

Actions

JR: Setup next couple of meetings
[After-meeting request]*Piotr: You mentioned the Maintainability category of Code Health. Could you capture some of your thoughts on this? I'd like to augment the Code Health page with that info at some point soon.

Misc

JR: next Code Health Group meeting is next week. I will forward the invite to our workgroup in the event that you want to/can attend (time is very US centric,sry).
MrG: have a look at sonarqube, it's a great tool to collect and track code metrics. For example, one of my side project: https://sonarcloud.io/dashboard?id=org.jmxtrans%3Ajmxtrans-parent or pick any PHP project from https://sonarcloud.io/explore/projects?languages=php&sort=-analysis_date
- JR: I think this is something we should look at. Perhaps you could get a demo set up for us with your contact unless you'd like to step us through it with you side projects. I know that you and I discussed this in the past, but I think it's worth diving into a bit.