𝗗𝗲𝗳𝗶𝗻𝗶𝗻𝗴, 𝗠𝗲𝗮𝘀𝘂𝗿𝗶𝗻𝗴, 𝗮𝗻𝗱 𝗠𝗮𝗻𝗮𝗴𝗶𝗻𝗴 𝗧𝗲𝗰𝗵𝗻𝗶𝗰𝗮𝗹 𝗗𝗲𝗯𝘁 𝗯𝘆 𝗚𝗼𝗼𝗴𝗹𝗲 In the latest paper by Google Engineers, they researched how to define, measure and manage Technical Debt. They use quarterly engineering satisfaction surveys to analyze the results. 𝟭. 𝗗𝗲𝗳𝗶𝗻𝗶𝘁𝗶𝗼𝗻 𝗼𝗳 𝗧𝗲𝗰𝗵𝗻𝗶𝗰𝗮𝗹 𝗗𝗲𝗯𝘁 Google took an empirical approach to defining technical debt. They asked engineers about the types of technical debt they encountered and what mitigations would be appropriate to fix this debt. This resulted in a collectively exhaustive and mutually exclusive list of 10 categories of technical debt, including: 🔹 Migration is needed or in progress: This may be motivated by the need for code or systems to be updated, migrated, or maintained. 🔹 Code degradation: The codebase has degraded or not kept up with changing standards over time. The code may be in maintenance mode, needing updates or migrations. 🔹 Documentation on project and application programming interfaces (APIs): Information on how your project works is hard to find, missing, or incomplete. 🔹 Testing: Poor test quality or coverage, such as missing tests or poor test data, results in fragility and flaky tests. 🔹 Code quality: Product architecture or project code must be better designed. It may have been rushed or a prototype/demo. 🔹 Dead and abandoned code: Code/features/projects were replaced or superseded but still need removal. 🔹 Team needs more expertise: This may be due to staffing gaps, turnover, or inherited orphaned code/projects. 🔹 Dependencies: Dependencies are unstable, rapidly changing, or trigger rollbacks. 🔹 Migration could have been better executed or abandoned: This may have resulted in maintaining two versions. 🔹 Release process: The rollout and monitoring of production need to be updated, migrated, or maintained. 𝟮. 𝗠𝗲𝗮𝘀𝘂𝗿𝗶𝗻𝗴 𝗧𝗲𝗰𝗵𝗻𝗶𝗰𝗮𝗹 𝗗𝗲𝗯𝘁 Google measures technical debt through a quarterly engineering survey. They ask engineers about which of these categories of technical debt have hindered their work. The responses to these surveys help Google identify teams that struggle with managing different types of technical debt. E.g., they found that engineers working on machine learning systems face different types of technical debt compared to engineers who build and maintain back-end services. They focused on code degradation, teams needing more expertise, and migrations being required or in progress. Then, they explored 117 metrics proposed as indicators of one of these forms of technical debt—the results were that no single metric predicted reports of technical debt from engineers. 𝟯. 𝗠𝗮𝗻𝗮𝗴𝗶𝗻𝗴 𝗧𝗲𝗰𝗵𝗻𝗶𝗰𝗮𝗹 𝗗𝗲𝗯𝘁 Over the last four years, Google has made a concerted effort to define better, measure, and manage technical debt. Some of the steps taken include: 🔸 Creating a technical debt management framework to help teams establish good practices 🔸 Creating a technical debt management maturity model and accompanying technical debt maturity assessment that evaluates and characterizes an organization's technical debt management process 🔸 Organizing classroom instruction and self-guided courses to evangelize best practices and community forums to drive continual engagement and sharing of resources. 🔸 Tooling that supports the identification and management of technical debt (for example, indicators of poor test coverage, stale documentation, and deprecated dependencies) It's important to note that zero technical debt is not the goal at Google. The presence of deliberate, prudent technical debt reflects the practicality of developing systems in the real world. The key is to manage it thoughtfully and responsibly. Check the full link in the comments. _______ If you like my posts, please follow me, @milan_milanovic, and hit the 🔔 on my profile to get a notification for all my new posts. Grow with me 🚀! #technology #softwareengineering #programming #techworldwithmilan #development