Technical Debt SIG/minutes/20170920

Attendance: 30 in bluejeans

Aaron S, Anthony Borba, Ariel, Arzhel, Brad, Cindy, Corey, Daniel K, Daniel Z, Deb, Elena, Erika, Gergo, Greg, JR, Jon, Katie, Kevin, Max, Mel, Michael H, Niharika, Niklas, Petr Pchelko, Riccardo, Stas, Timo, Tyler, Victoria, Željko

Agenda

• Technical Debt

• Purpose of the Technical Debt Special Interest Group (SIG)

• Overview of Tech Debt Program

• What to expect moving forward

• Q&A

Notes

Feel free to ask questions at any point, not just during Q&A at the end

JR presented a little slide deck

slide1

• Defining Technical Debt
  • Dan Rawsthorne variation
• lost productivity, lower quality, and unhappy developers

slide 2

• Purpose of the SIG
  • Work to remove accrued tech debt and help avoid incurring more
  • Define tech debt, identify/refine backlog of tech debt, work with Code Health Group
• Those who work with the code are in the best position to identify biggest problems
• Many definitions of tech debt exist and are in use, so this group needs to find our own shared understanding
• Code Health: https://www.mediawiki.org/wiki/Code_Health (link to Code Health Group is at the bottom of that page)

slide 3

• Purpose of the SIG (continued)
  • SIG is not responsible for specific outcomes
  • Work with other groups and initiatives
  • Mix of synchronous and asynch channels for participation

slide 4

• Tech Debt program
  • https://www.mediawiki.org/wiki/Wikimedia_Technology/Programs#Program_3:_Addressing_technical_debt
  • Help reduce existing debt and avoid accumulating more

slide 5

• Tech Debt program (continued)
  • Sponsored by CTO Victoria; GregG is responsible for it; JR is accountable (aka is running the program)

slide 6

• Tech Debt program (continued)
  • Goals: Shared understanding, work with devs and teams to help reduce existing and to help avoid accruing new
  • No single solution across all teams to reduce tech debt
  • Work with teams to think about code health
  • Focus on high-value/high-impact technical debt

slide 7

• What to expect next
  • Build shared definition
  • Blog posts, office hours
  • Help teams identify and prioritize their tech debt
  • Work with Code Health Group

Q&A

• VC (in chat): In my mind it's all about continuous attention to the entire code base and not just product features
• DanielK (via chat): how to sell that to product owners?
• VC (in chat): Product owners need to be our partners in getting that done. It's 101
• DanielK (via chat): will they be happy to reserve 20% dev time for addressing or avoiding tech debt?
• VC: I don't know about the percentage--this program should work on that. But it's an issue they can't ignore. Eventually a shaky foundation will come back to bite you
• Timo: Are we talking about routinely reserved time vs adressing specific debts?
• VC: This program is about identifying major tech debt, and addressing those.
• KS (in chat): i suspect some teams can chip away in bits, but others might need to swarm intensively at times
• DanielK: My experience is that feature development would need to go at least 20% slower to avoid incurring new tech debt. That's a made up/estimated number. My impression is that in the past people have felt that tech debt would bite someone else, and they have gotten pressure from their manager, so haven't taken that time. It's a cultural change.
• Katie (in chat): I agree that communicating about this such that product and other stakeholders understand (or at least accept) this work as necessary is something that is going to require nontrivial effort.
• VC: I could not agree more. Culture. Leadership is a part too. When you have tech debt, development gets slower. At past job, a one-line change took 3 weeks, due to tech debt.
• JR: As a dev, you know that incuring tech debt will cause problems down the line. I agree that there is a cultural change, especially with avoiding new tech debt. A conversation with Product Owner about whether it's worth cutting a corner to hit a date is sometimes all it takes.
• Gergo (in chat): The kind of tech debt people think of is people writing code with no tests, or hard-to-read code, or something. the Foundation is decent at that these days IMO. the real problematic area is that no one really is responsible for improving vast areas of core code. so it's not really a "code health" thing
• Katie (in chat): Also: When we "try" things in a lightweight way, and they work and suddenly become prod features...Rapid testing needs some rules.
• VC (in chat): it's about overall product health
• JR: "Product health" vs. "code health". I'm curious what is the distinction.
• VC: I don't believe that you can deliver a healthy set of features on an unhealthy code base. Sometimes the code wasn't bad at the time, but now there are better approaches. One of the worst things about tech debt is that it slows future progress. Think about our 2 parsers. It's about leadership.
• Max (in chat): I think that the main problem is that with lots of our code, writing tests is really hard
• DanielZ (in chat): re: priorization of technical dept. isn't technical debt by definition the stuff that has been prioritzed as "low" in the past.. or it would not be debt?
• Gergo (in chat): random example: when MediaWiki was written, dependency injection was not a thing in the PHP world. the code wasn't necessarily bad, for the standards of that time
• JR (in chat): Some technical debt accumulation isn't due to conscious decisions.
• Gergo (in chat): then the understanding of how to write maintainable code progressed. how to apply that progress to core?how to apply that progress to core? no one's responsibility!no one's responsibility!
• VC (in chat) The trick is to be specific about the priorities of the tech debt program - no more than three to start with!Message from Victoria Coleman: everyone agrees that tech debt is bad in principle. It bites when we get specificeveryone agrees that tech debt is bad in principle. It bites when we get specific
• JR: Orphaned code has come up a few times. We are trying to inventory owned and orphaned code. For unowned code, try to find an owner, and/or consider sunsetting.
• Greg: Sunsetting Working Group came out of a few conversations. OCG was a primary example of a sunsetting candidate. Lack of owner doesn't inherently mean something should be sunsetted. Don't be scared that the group will just throw things away. The WG is working on creating guidelines about what to sunset and how to do so responsibly. Notes are public. Link: https://www.mediawiki.org/wiki/Sunsetting_Working_Group

Next steps

• JR: I plan to pull together more concrete details about the Tech Debt program, and start to engage with various groups. One of my big next steps is to come to a good shared understanding of what we include when we talk about tech debt. Focus. My past experience is that when an initiative gets support, people start to try to throw other issues into it to get them solved too. I want to work with individual teams to help them identify their top 3-5 highest value tech debt problems, as a first step to understanding how we can reduce existing tech debt.
• JR: There is another kickoff video call tomorrow. There will be a series of blog posts over the coming weeks. Publicize upcoming tech debt office hours.
• JR: If you have other ideas or suggestions, don't hesitate to reach out.

Actions

DONE:JR Publish these notes (or delegate doing so) DONE:JR Add TechCom to the "Consulted" list