[DevoxxGR2024] Socio-Technical Smells: How Technical Problems Cause Organizational Friction by Adam Tornhill
At Devoxx Greece 2024, Adam Tornhill delivered a compelling session on socio-technical smells, emphasizing how technical issues in codebases create organizational friction. Using behavioral code analysis, which combines code metrics with team interaction data, Adam demonstrated how to identify and mitigate five common challenges: architectural coordination bottlenecks, implicit team dependencies, knowledge risks, scaling issues tied to Brooks’s Law, and the impact of bad code on morale and attrition. Through real-world examples from codebases like Facebook’s Folly, Hibernate, ASP.NET Core, and Telegram for Android, he showcased practical techniques to align technical and organizational design, reducing waste and improving team efficiency.
Overcrowded Systems and Brooks’s Law
Adam introduced the concept of overcrowded systems with a story from his past, where a product company’s subsystem, developed by 25 people over two years, faced critical deadlines. After analysis, Adam’s team recommended scrapping the code and rewriting it with just five developers, delivering in two and a half months instead of three. This success highlighted Brooks’s Law (from The Mythical Man-Month, 1975), which states that adding people to a late project increases coordination overhead, delaying delivery. A visualization showed that beyond a certain team size, communication costs outweigh productivity gains. Solutions include shrinking teams to match work modularity or redesigning systems for higher modularity to support parallel work.
Coordination Bottlenecks in Code
Using behavioral code analysis on git logs, Adam identified coordination bottlenecks where multiple developers edit the same files. Visualizations of Facebook’s Folly C++ library revealed a file modified by 58 developers in a year, indicating a “god class” with low cohesion. Code smells like complex if-statements, lengthy comments, and nested logic confirmed this. Similarly, Hibernate’s AbstractEntityPersister class, with over 5,000 lines and 380 methods, showed poor cohesion. By extracting methods into cohesive classes (e.g., lifecycle or proxy), developers can reduce coordination needs, creating natural team boundaries.
Implicit Dependencies and Change Coupling
Adam explored inter-module dependencies using change coupling, a technique that analyzes git commit patterns to find files that co-evolve, revealing logical dependencies not visible in static code. In ASP.NET Core, integration tests showed high cohesion within a package, but an end-to-end Razor Page test coupled with four packages indicated low cohesion and high change costs. In Telegram for Android, a god class (ChatActivity) was a change coupling hub, requiring modifications for nearly every feature. Adam recommended aligning architecture with the problem domain to minimize cross-team dependencies and avoid “shotgun surgery,” where changes scatter across multiple services.
Knowledge Risks and Truck Factor
Adam discussed knowledge risks using the truck factor—the number of developers who can leave before a codebase becomes unmaintainable. In React, with 1,500 contributors, the truck factor is two, meaning 50% of knowledge is lost if two key developers leave. Vue.js has a truck factor of one, risking 70% knowledge loss. Visualizations highlighted files with low truck factors, poor code health, and high activity as onboarding risks. Adam advised prioritizing refactoring of such code to reduce key-person dependencies and ease onboarding, as unfamiliarity often masquerades as complexity.
Bad Code’s Organizational Impact
A study showed that changes to “red” (low-quality) code take up to 10 times longer than to “green” (high-quality) code, with unfamiliar developers needing 50% more time for small tasks and double for larger ones. A story about a German team perceiving an inherited codebase as a “mess” revealed that its issues stemmed from poor onboarding, not technical debt. Adam emphasized addressing root causes—training and onboarding—over premature refactoring. Bad code also lowers morale, increases attrition, and amplifies organizational problems, making socio-technical alignment critical.
Practical Takeaways
Adam’s techniques, supported by tools like CodeScene and research in his book Your Code as a Crime Scene, offer actionable insights:
– Use Behavioral Code Analysis: Leverage git logs to detect coordination bottlenecks and change coupling.
– Increase Cohesion: Refactor god classes and align architecture with domains to reduce team dependencies.
– Mitigate Knowledge Risks: Prioritize refactoring high-risk code with low truck factors to ease onboarding.
– Address Root Causes: Invest in onboarding to avoid mistaking unfamiliarity for complexity.
– Visualize Patterns: Use tools to highlight socio-technical smells, enabling data-driven decisions.