How to Take Google Ideas and Build Your Own Architectural Quality Control (Category Architecture)
In the past. post "Understanding Architectural Complexity, Maintenance Burden, and Developer Sentiment - a Large-Scale Study." Now, what I'd like to talk about is the practical steps you can take at home if you're not Google, but you want to control the quality of architecture and the amount of debt you owe.
1Formulate “maintenance burden” so that it can be considered The most practical option is the proportion of bugfixes vs. features for the period: % of Bug tasks in the tracker Percentage of PR/committees tied to Bug
- % LOC (or at least files)changed for the sake of Bug
2Gather a minimum of data (usually) Git/PR Logs: Who/When/What Changed (changed files, size).
- Issue tracker (Jira, etc.)type of task (bug/feature), component/service, command. Dependency graph: relationships between packages/modules/services (from build graph, import graph, API calls). Active coding time on tasks or DAT (Diff Authoring TIme)So much for the banned in Russia Meta and about which I have already told If there is no Active Coding Time, start with a proxy: lead time PR, review time, batch size (And then do the ACT.)
3Architectural metrics: start “cheap”, then complicate The metrics from the whitepaper above are cool, but complicated. I mean, - Propagation Cost (PC): How widespread are changes in dependencies **- Decoupling Level (DL)**How well the system is decomposed into independent modules There's an academy. DV8 from the authors of the original study (Yuanfang Cai, Rick Kazman) Or conditional Sonar as a commercial instrument. But it's enough to start. Track cycles at the module/service level (SCC)
- Consider fan-in/fan-out, transitive fan-out Track co-change clusters: files are often changed together, although "architecture" should not Under Pareto rule, we'll find that. 20Percentage of problems that cause 80pain
4Put everything in a regular report. (quarterly/monthly) At the repo/service/command level:
- Trend coupling/cycles/co-change
- Trend bugfix ratio
- Micro-poll. 1 Quarterly question: “How much debt/complexity prevented you from working?” It is important to look not for the guilty, but for the problem in the system: high coupling + growing bugfix ratio = candidate #1 tech investment
If you use this algorithm, you will have a set of cards on your hands, with which no tech debt is not afraid. You will have arguments to refactor in numbers. (And the conversation with the business will be in a language they understand.)
- You will have a clear priority: which 2–3 Hotspots should be repaired first. You will see early degradation signals: catch trends before the team goes into eternal bugfix.
- You will improve DevEx and the speed of delivery of features as a consequence
But it's important not to screw up and step into anti-patterns. Do not turn metrics into KPI people / teams - there will be gaming Do not set the same absolute thresholds on metrics - you need basic norms "what's OK" for your domain; Don't try to get one metric of tech debt - it's multidimensional and metrics are a signal, not a sentence. Next, we need a design review and an engineering assessment of the problems found
If I did it in the company, I would try it.
- Ride the pilot on 10–20 repositories / services Collect a base panel of metrics listed above
- Waited for the results, for example, quarter.
- I'd do point refactorings. (Now refactoring becomes much cheaper if it is done using AI tools.) Compare before/after by bugfix ratio and delivery speed If the metrics had improved, I would have planned to continue rolling.
In general, from the point of view of the algorithm, there is no rocket science, but the devil lies in the details:)
#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes