On Tech Debt: My Rust Library Is Now A CDO
- Armin Ronacher tl;dr: The author describes how they dealt with tech debt in their Rust library caused by a dependency. When the dependency was flagged as insecure by RUSTSEC, users demanded action. Alternatives were unappealing, so the author merged the dependency's code into their own library, effectively "collateralizing" the tech debt and upgrading it from "junk" to "AAA" status.featured in #501
Generating Code Without Generating Technical Debt?
- Reka Horvath tl;dr: GPT and other large language models can produce huge volumes of code quickly. This allows for faster prototyping and iterative development, trying out multiple solutions. But it can also leave us with a bigger amount of mess code to maintain… This article explores several ways how to improve the code generated by these powerful tools and how to fit it into your project.featured in #429
How Google Measures And Manages Tech Debt
- Abi Noda tl;dr: The first part describes the categories of tech debt and the second part explores how categories may be measured, providing insights on how to determine whether teams are struggling with technical debt and the types of tech debt they’re struggling with. The final part of this paper provides several tactics that may help reduce tech debt.featured in #423
The 25 Percent Rule For Tackling Technical Debt
- John DeWyze tl;dr: rom Shopify’s engineering team, 25% of time is divided amongst 3 types of tech debt: (1) Daily Debt: engineers spend 10% - 4 hours a week - if they want to “tidy” or improve code in any area they encounter. (2) Weekly Debt: 10% - 4 hours a week - is spent on tech debt that can be solved by adding a card or issue to a sprint. (3) Monthly and Yearly debt: 5% - or two hour long meetings a week - is spent on future planning.featured in #393
A Framework For Prioritizing Tech Debt
- Max Countryman tl;dr: "Now with a complete list of your tech debt as it stands go through each and answer the following questions: (1) If we choose to do nothing, will this issue become worse, remain the same, or improve? (2) If it'll become worse, how quickly will it degrade? (3) If it remains the same, how much disruption is it causing today? (4) If it'll improve, at what point will it improve to the degree it's no longer an obstruction?"featured in #384
We Invested 10% To Pay Back Tech Debt; Here's What Happened
- Alex Ewerlöf tl;dr: Alex discusses how "Tech Debt Friday" started at his org, what was learned and how it's executed: (1) We spend 10% of our time to deal with tech debt. (2) The first rule is not to create debt in the first place. (3) The PR that creates tech debt should come paired with the issue to deal with it. And more.featured in #383
featured in #363
Beautiful Technical Debt (2022)
- Rinat Abdullin tl;dr: “What looks like a technical debt in a software solution, might be the most efficient way for people to deliver business value in a given situation. There is a beauty in that, if observed from a distance.”featured in #288
How To Deal With Tech Debt At The Scale Of Super App
- Maksim Koutun tl;dr: "We want to share how we decided to work with technical debt and how Evolutionary architecture and SRE help us balance innovation and quality in mobile development." Maksim provides several examples, such as how each team can dedicate up to 20% of their capacity to technical improvements.featured in #283
Hunting Tech Debt Via Org Charts
- Marianne Bellotti tl;dr: "The types of problems organizations have are heavily influenced by their incentive structure." Marianne describes the types of problems you'll find in various org structures i.e. in engineering led orgs, orgs where engineering reports to product, or security, or in flat orgs. She concludes "the best organizations at managing technical debt tend to be the ones that have a thoughtful process in place to adjudicate competing incentives."featured in #281