Code Health Group/20170822

Attendees: JR, Erika, Kevin, Erik, Greg

Agenda:

   - Technical Debt
   - Current activities
   - Defining Code Health 
   - What are the attributes of Code Health?
   - Extensions session at Hack-a-thon

   - Logistics
   - Meeting cadence 1 /mo?

Actions/Next Steps:

- further refinement of Code Health Attributes

- JR/Erika to work on

- JR to schedule recurring Code Health meeting (monthly)

- Legoktm to provide summary of Extensions best practices from wikimania hack-a-thon session

Notes:

JR: How often do we want to meet as a core group? Monthly? Calendars are pretty full, so I don't want meetings to get in the way of progress. A monthly meeting might encourage more asynch progress.

Erika: I'm fine monthly. We should set outcomes we want to achieve, and those might drive meeting frequency.

Greg: +1

JR: Another item: Erik, do you want to be part of the core team?

Erik: I'm fine with that.

JR: Maybe today we can discuss outcomes. Personally I have been focusing on tech debt [since there is a program for it]. But that doesn't have to be a core outcome of the CHG. Another thing I would like to start developing with this group of people is a better sense of what we mean when we say "code health". Some may be measurable, some less. Other ideas?

Erika: I can see there could be "code health seasons", with different focuses at different times. There are a lot of topics that code health can cover, and I don't think we can take on very many at a time. I like your instinct to define what code health means

JR: Parallels between tech debt work and CH work. A lot of tech debt issues are symptoms of bad code health. A number of teams have already filed tasks tagged TechDebt, but we should define what's in that umbrella. A lot of existing tasks ... Tech debt comes from not having code health. Standards, design patterns, ultimately are good for code health; when not followed, tech debt can result.

Erika: Isn't a team looking at tech debt?

Kevin: Technology has a TD program, which JR is now the owner; There is a code review office hour; Brion Vibber is working on something related to code review

Erika: Research has a monthly showcase, allowing people to benefit what they do. Is a goal of our group to push information out, in a concerted way? Creating a centralized point through which all this travels?

JR: I think so. At google, the group like this one is a hub. Not that everything starts at the hub, but that it flows through the hub. If we hear about something, maybe get it published as a blog or on a tech talk. I was thinking we could expand the code review office hour and have a time for people to discuss code health. It will build what we think code health is. I'm learning by looking at "tech debt" tasks, where there are things that I wouldn't have thought of as tech debt, but they make a good argument. Marketing and communication: Here's the CHG which started up. Build a name that people associate with related work.

JR: Update on Tech Debt initiatives. I was going to have Kunal talk about his hackathon session about quality extensions. A lot of the topics there seemed to be about code health.

JR: Over the last few weeks, I have been pulling together a definition of tech debt, and updated wiki pages. One took over the existing tech debt page, and the other is more about the program. Over the next few weeks, I would like to put out some blog posts. I'm working with Melody. Hoping for a series of posts, to avoid a flash in the pan. Multiple posts may keep it more in the center of mind; people who miss one can catch another. That will continue to evolve. Links: Tech debt definition: https://www.mediawiki.org/wiki/Technical_debt

Program: https://www.mediawiki.org/wiki/Technical_Debt_Program

Code Health: https://www.mediawiki.org/wiki/Code_Health

CHG: https://www.mediawiki.org/wiki/Code_Health_Group

JR: In addition to that, I have been going through phab #Tech-debt and there are a ton. Looking at recent ones, if it's not clear to me why something is tech debt, I have been sending a friendly question asking them how they see it as tech debt, and referring them to the definition.

Tech Debt Programs goals (the middle program here, Program 3):

   https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/Goals/201718Q2

JR: There was also a "tech debt bash" session at the Dev Summit 2017, which was interesting to hear what people think about tech debt

<insert link to video here>

JR: After we define it, how to we start to address it? There are a number of different approaches. We'll probably develop this over the next couple weeks or so. It's probably going to be making sure that individual teams are bought into tech debt. They can figure out what will be most impactful for them. Someone outside would have trouble identifying that. One approach is to talk to tech managers. Next Tuesday, JR will talk with Technology Dept mgrs. Start with "what are the top 5 tech debt items that you would like to get addressed?"

Greg: Talking with tech-mgt may inform Q2 goals. We should talk about what we want out of this group over the short to medium term. So far, it's mostly on JR, but what could we do as a group to keep this going?

JR: I think we'll learn as we go. The hope is that the CHG will help the org consolidate its efforts. So we probably won't have just one thing going on at a time, but if there are more than JR can handle, then we can seek additional help to get that done. Something like tech debt is an umbrella, but code health is even broader. We could focus on "better coverage of unit tests". That would benefit tech debt, but would also benefit a very specific area.

Erika: Any measurements in tech debt areas?

JR: The closest thing is stuff being recorded in phab, but that's not very meaningful.

Greg: Very inconsistent.

Erika: One of my concerns is: How to know if we meet outcomes if we don't have measurement. Tech Debt covers a lot of areas. Is it areas we need to refactor? Bugs we haven't fixed? Code standards and readability? If we're going to define the things, we should measure how pervasive they are now, so when we improve things, we can point to numbers. It's a language that resonates with the product side of the org, which does oversee some engineering work.

JR: I agree. There will be some easily measurable, like code coverage. There may be other areas of code health that are harder to measure, but maybe not impossible. Either not a number, or not currently being collected. In phab, there is a workboard that breaks tech debt into testing, refactor/rewrite, split, etc. We could look at how they have broken things out. There are dozens/hundreds in "unsorted".

https://phabricator.wikimedia.org/project/view/609/

JR: What comes to mind from "code health"?

Erik: To me, it means I can change something and not get massively frustrated. Not having to spend hours and hours testing to figure out what to do. How obvious is it what is happening? How many assumptions are baked in.

JR: I think that's it in a nutshell. Code that is not intuitive...coding standards can help with readability, but the design still might not jump out at you.

Erik: It's hard to help that from a code group standpoint. I have written code that is unintelligible that I only realize 6 months later could have been done easier. Sometimes things just aren't obvious.

JR: Those would probably be difficult to measure, outside the group that works with that code. It's a reach to say that anyone familiar with coding could quickly understand some code. Maybe a good goal, but not always practical. Is there a way to view those things at a component layer: Those who modify the code most, what would they look at as aspects of code health that need improvement. Those people would also be in the best position to say [what needs to be improved or how]. In most cases, if you can go into code and someone feels uncomfortable because they might break something or might not know they did, that could use attention. On the wiki page, the areas were:

• Simplicity
• Maintainability
• Readability
• Testability

JR: We could look at what those mean, and how they could be measured.

Erika: I keep coming back to the google code health group that blogs a lot. One thing that jumps out at me is: "The CHG works on things that universally help...." When we talk about coding standards, we have a number of different languages and frameworks. If we really want to make a difference, we won't make much traction working with individual groups. We should target what is universal across everything. Working at a higher level. Meta code health level.

Link to blog post: https://testing.googleblog.com/2017/04/code-health-googles-internal-code.html

"What the Code Health group does is work on efforts that universally improve the lives of engineers and their ability to write products with shorter iteration time, decreased development effort, greater stability, and improved performance."

JR: One thing you'll notice in their posts is that they have the primary "what it is" post, but they have other posts that can be very technical. Some look at some specific code and show how you might refactor it. This could help because if we say 'maintainability", what do we really mean. They have given examples. I think that would be pretty beneficial internally, if we can get groups who make improvements, they could write a blog post explaining what they did. I agree Erika that the universal part is important. Google also has a lot of languages and frameworks. Whether you are using php or java, you should have standards. Start off encouraging the behavior, and hopefully we can measure. At the very end, you can flip a switch and block commits that don't comply. That's only at the very end. For google, the CHG was in the position to enforce that.

Erika: Enforcement is alway tricky in communities. I hope we don't become enforcers, but cheerleaders and educators. Maybe one week per quarter will be code health week, and "this week we're talking about X", and maybe do measuring, and provide incentives.

JR: Max from google CHG said you really don't want this to be top-down. Best as grassroots. Execs are great at providing kudos. Victoria has a big push on tech debt, so there could be a "tech debt improvement of the month" reward.

KS: Testability is great, but so is actually having tests. I think that's part of code health. Not sure if it also extends out to CI, deployment, etc.

JR: I think it includes tests, because they help give devs confidence. That makes them more productive. Part of that chain is CI, and maybe eventually continuous deployment. That gives devs feedback as quick as possible. At google, a lot of this is coming out of the tooling and infrastructure groups. I'm not sure how that would be broken out here. It probably should be mentioned.

JR: Next step: I would like to hammer out the code health wiki page. Build it out more, so someone can understand what "maintainability" means, vs. "simplicity", etc. Erika: I'll help with that.

JR: I think the other TODO, which Kunal is already planning, is to pull in the best practices for extensions. I think a lot of those will be code health related. We can go over that next meeting.

JR: Should anyone else be in the steering committee? I don't think we have reached out to tech managers. I could reach out to tech-mgt

KS: I would say not just managers. All of Technology and Audiences. Maybe even volunteers? wikitech-l?

Erika: It's hard for a lot of volunteers to have a broad perspective. I'm a bit gunshy about bringing volunteers into certain kinds of discussions...I'm still somewhat new to this environment.

JR: We could evolve to that. Maybe reach out to specific people.

Erika: There are also overarching areas, like extensions.

JR: I collected 18-19 people interested in a tech debt SIG (to have a dialog). These are both WMF and outside.

KS: There was also the testing initiative from a couple years back.

Greg: Maybe some notes from that would be worth reading.

JR: Yup, I read some.

Regrets

Legoktm: Sorry, I didn't realize the wifi at the library would be so bad. At Wikimania I led a group that started work on <https://www.mediawiki.org/wiki/Best_practices_for_extensions>, (the idea which mostly came from this group). I have a little more cleanup to do and then was going to present it to wikitech-l for further comments and refinements. I've also been working on aggregating PHPCS stats across extensions (<http://phpcs-dashboard.wmflabs.org/sniffs/>) so you can see what categories have issues, and which extensions are failing those issues. I was thinking we could organize a "sniff of the week" or something and help people fix all the issues in their codebase or something.