Understanding Architectural Complexity, Maintenance Burden, and Developer Sentiment - a Large-Scale Study (ICSE’25) (Category Architecture)
I finally got my hands on writing about this. fancy whitepaper about the connection of the quality of architecture with the load on support of the solution and perception of the engineers of the project itself. Lead author of this article was Yuanfang Cai, a professor at Drexel University and author of metrics applied, and the Google Developer Infrastructure/Engineering Productivity Research team. (Ciera Jaspan et al.)
The authors took the data.
- 1200+ Projects within Google (C++/Java). Development logs: commits, LOCs (lines of code) and Active Coding Time; separately measured them in terms of "fitches" vs "bugfixes"
- 7200 The answers of engineers from a regular survey: how much tech debt / excess complexity interfered with the work (Google’s “Measuring Developer Experience with a Longitudinal Survey” handler)
The purpose of the entire squat was to replace the “feelings of tech debt” with measurable connections: architecture → the burden of maintenance → the mood of developers. Google has already published a cool article “Defining, Measuring and Managing Technical Debt”. handler
They measured the following three categories. 1Architectural complexity - Propagation Cost (PC): How widespread are changes in dependencies **- Decoupling Level (DL)**How well the system is decomposed into independent modules **- Architectural smells.**Cyclical dependencies, co-change without overt dependencies, unstable interfaces, inheritance problems, etc. 2️⃣ Maintenance burden Share of effort on bugfixes: commits, LOC (lines of code), ACT (active coding time) 3️⃣ Developer sentiment Answers to questions from surveys such as "does tech debt slow me down"
The methodology looked like this. For each project, PC/DL/smells are considered dependency graph+ "bugfix ratio" by history of change.
- Further statistical analysis. (correlations/significance) three-layer
In the end, they got the results that
- More complex architecture. (PC↑, smells↑) The team spends more effort on bugfixes and less on development. The more “feature work” a team has, the less engineers say that tech debt slows them down.
- "Architecture".> Discontent is largely manifested through the growth of bugfixes: when you live in support, tech debt becomes tangible.
Separately, it should be noted that the study found a correlation, but this is not a cause-and-effect relationship. But it's a common pattern for complex research methodologies that you can't run an a/b test.
In next post I'm going to tell you what I'm thinking, and what can I take away from this, so I can control the quality of the architecture and not become technically bankrupt.
P.S. I talked about many articles by the guys from Google, they have a perfectly built methodology and have very interesting results - you can see more in a selection of two posts: 1 and 2
#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes