Skip to content
back to the archive page
#Architecture

Adapting Google’s Ideas to Track Architectural Quality (Category Architecture)

#Architecture #Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

In the previous post, we discussed Google’s whitepaper “Understanding Architectural Complexity, Maintenance Burden, and Developer Sentiment — a Large-Scale Study.” Now I’d like to consider practical steps for a company that is not Google but still wants to monitor architectural quality and technical debt.

1️⃣ Define maintenance burden in measurable terms The most practical starting point is the proportion of bug fixes versus features over a period:

  • The percentage of Bug tasks in the tracker.
  • The percentage of PRs or commits linked to a Bug.
  • The percentage of lines of code, or at least files, changed to fix bugs.

2️⃣ Gather the minimum data, which usually already exists

  • Git and PR logs: who changed what and when, including changed files and change size.
  • An issue tracker such as Jira: task type, bug or feature, component or service, and team.
  • A dependency graph between packages, modules or services, derived from build graphs, imports or API calls.
  • Active coding time by task, or DAT (Diff Authoring Time), which Meta, banned in Russia, has promoted and which I discussed earlier.
  • If active coding time is unavailable, start with proxies: PR lead time, review time and batch size. Then do collect ACT.

3️⃣ Start with inexpensive architecture metrics and add complexity later The whitepaper’s measures are powerful but complicated:

  • Propagation Cost (PC): how widely changes propagate through dependencies.
  • Decoupling Level (DL): how well the system is split into independent modules.

There is DV8, from the original researchers Yuanfang Cai and Rick Kazman, or a commercial tool such as Sonar. To start, though, it is enough to:

  • Track module- or service-level cycles using strongly connected components, or SCCs.
  • Count fan-in, fan-out and transitive fan-out.
  • Track co-change clusters: files that often change together even though the intended architecture says they should not.

By the Pareto rule, this should uncover the 20% of problems causing 80% of the pain.

4️⃣ Combine it into a monthly or quarterly report At repository, service or team level, show:

  • Trends in coupling, cycles and co-change.
  • The bug-fix ratio trend.
  • A tiny quarterly survey with 1 question: “How much did technical debt or complexity get in the way of your work?”

Look for a system problem rather than someone to blame. High coupling plus a rising bug-fix ratio makes a #1 candidate for technical investment.

This approach gives you useful cards to play against technical debt:

  • Numerical arguments for refactoring, in a language business stakeholders understand.
  • Clear priorities: which 2–3 hotspots to fix first.
  • Early signs of deterioration, before the team becomes trapped in endless bug fixing.
  • Better DevEx and faster feature delivery as a result.

Avoid the obvious traps:

  • Do not turn these measures into individual or team KPIs; people will game them.
  • Do not apply identical absolute thresholds everywhere. Establish what is normal for your domain.
  • Do not look for a single technical-debt score. Debt is multidimensional, and metrics are signals rather than verdicts. Design reviews and engineering judgment still need to assess the problems found.

If I were doing this in a company, I would:

  • Run a pilot across 10–20 repositories or services.
  • Build a basic dashboard of the measures above.
  • Let results accumulate, perhaps for a quarter.
  • Carry out targeted refactoring, which is becoming much cheaper with AI tools.
  • Compare the bug-fix ratio and delivery speed before and after.
  • Plan a wider rollout if those measures improved.

There is no rocket science in the overall approach, but the devil is in the details :)

#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes