User:KSmith (WMF)/Technical debt thoughts
Scope of this initiative edit
- Top priority: Finding owners for orphaned code
- Also: Defining a process for transferring ownership as needed
- Second priority: Helping teams manage their own tech debt
- Includes paying down existing debt, and minimizing taking on new debt
- Later: Help work through the massive backlog of phab tasks
- Perhaps eventually: Address the quality/fragility of code, as measured by incidents
Random thoughts edit
Should we distinguish between "good" and "bad" tech debt? [VC: I don't suppose that matters]
Questions for product managers [VC: My sense would be that we ask PMs to balance the load of the engineering teams between features for foundation level goals, features requested by customers, features decided by the team to improve their product without receiving a request from a customer and tech debt]
- Do you feel pressure to rush work to the point of creating new tech debt?
- Are you comfortable with engineers reducing/avoiding tech debt while they are working on features and bugs? "It's not done until the code is clean."
- Would you be comfortable allocating chunks of developer time to paying down old tech debt?
- Do you accept the estimate that at least 20-25% of developer time should go toward avoiding/reducing tech debt?
Questions for engineers
- Do you feel pressured to rush work to the point of creating new tech debt?
- Are you comfortable advocating to the product manager that they should prioritize tech debt reduction
- Would you support a norm of reducing/avoiding tech debt while you are working on features and bugs? "It's not done until the code is clean."
- Do you accept the estimate that at least 20-25% of developer time should go toward avoiding/reducing tech debt?
- How would you assess your tech debt backlog? Is it growing or shrinking?
Figure out how to represent Tech Debt work in phab
- There is already a #Tech Debt project with a categorized workboard
Get public statement of commitment from Victoria and Wes [VC: Yes]
Can tech debt be quantified?
- No, at least from a practical standpoint
Examples of teams tackling tech debt well, using different approaches
- Decision to rewrite a 1000-line extension from scratch, with a tight spec, rather than continuing to struggle fixing a legacy abandoned codebase
- Heavy refactoring as part of a project to upgrade a major third-party library
How to handle tech debt in code that has no clear owner?
Ideas edit
Have a cross-team "Product Owner/Product Manager of Tech Debt", who prioritizes (based on input)
Dedicate one slide per quarterly checkin deck describing what the team has done/will do about tech debt (including introducing new)
Require any proposal to deploy something new to include a plan for dealing with long-term tech debt (and/or sunsetting the feature/project)
Recognize teams and engineers for paying back tech debt - eg Tech Debt Basher of the Month
Links and quotes edit
https://en.wikipedia.org/wiki/Technical_debt
"Finally, remember: Your architecture is a cold blooded loan shark, who will just as soon take your installments, as he will bust your project’s kneecaps over a missed payment." (from http://www.softwareandi.com/2011/12/how-to-measure-technical-debt.html)
"In the past, I have stated that the ScrumMaster’s #1 issue on a Team is likely to be getting the Team to write Quality Code, which is code that the Team can change easily." and "So, my definition of Technical Debt is: Technical Debt consists of deficiencies in the code, technical documentation, development environments, 3rd-party tools, and development practices, which makes the code hard for the Team to change." [emphasis changed] (from https://blog.3back.com/scrum-questions/so-what-is-technical-debt-in-scrum-anyways/)
Meeting notes edit
https://etherpad.wikimedia.org/p/TechDebt-2017-01-27 - Victoria, Greg, and Kevin, deciding on the scope of this initiative, and immediate next steps.