Identifying Coordination Problems in Software Development: Finding Mismatches between Software and Project Team Structures

Today’s dynamic and iterative development environment brings significant challenges for software project management. In distributed project settings, “management by walking around” is no longer an option and project managers may miss out on key project insights. The TESNA (TEchnical Social Network Analysis) method and tool aims to provide project managers both a method and a tool for gaining insights and taking corrective action. TESNA achieves this by analysing a project’s evolving social and technical network structures using data from multiple sources, including CVS, email and chat repositories. Using pattern theory, TESNA helps to identify areas where the current state of the project’s social and technical networks conflicts with what patterns suggest. We refer to such a conflict as a Socio-Technical Structure Clash (STSC). In this paper we report on our experience of using TESNA to identify STSCs in a corporate environment through the mining of software repositories. We find multiple instances of three STSCs (Conway’s Law, Code Ownership and Project Coordination) in many of the on-going development projects, thereby validating the method and tool that we have developed.

💡 Research Summary

The paper addresses a fundamental challenge in contemporary software development: the growing difficulty of “management by walking around” in distributed, iterative environments. Project managers often lack real‑time insight into team activities, which can lead to missed warnings and sub‑optimal coordination. To remedy this, the authors introduce TESNA (TEchnical Social Network Analysis), a method and supporting tool that simultaneously analyses the evolving social network of developers and the technical network of software artifacts.

Data sources for TESNA include version‑control logs (CVS), email archives, and chat histories. From CVS, file‑level commit histories and author information are extracted; from email and chat, sender‑receiver pairs and communication frequencies are derived. After cleaning and anonymising the raw logs, the information is modelled as a bipartite graph: one set of nodes represents developers, the other set represents source files. Edges in the social layer capture communication intensity, while edges in the technical layer capture code dependencies (e.g., imports, function calls). By sliding a two‑week window over the project timeline, TESNA produces a series of time‑stamped network snapshots that reveal how collaboration patterns and code structure co‑evolve.

The core theoretical contribution is the definition of three Socio‑Technical Structure Clashes (STSCs) based on pattern theory.

1. Conway’s Law Clash – occurs when the organizational hierarchy (teams, departments) does not align with the modular decomposition of the codebase. Misalignment typically manifests as high inter‑team communication overhead and increased defect density.
2. Code Ownership Clash – arises when a file lacks a clear owner and is edited by many developers in rapid succession. This situation is associated with merge conflicts, higher bug injection rates, and reduced code quality.
3. Project Coordination Clash – reflects a discrepancy between the project manager’s prescribed workflow (e.g., sequential phases) and the actual collaborative workflow observed in the commit and communication logs. Such a clash often leads to schedule slippage and rework.

To validate TESNA, the authors conducted an empirical study in a large corporate setting involving five concurrent development projects spanning twelve months and involving 38 developers. For each project, TESNA generated network visualisations and a dashboard that highlighted STSC hotspots. The findings were striking:

• Conway’s Law Clash was detected in four projects, affecting on average 27 % of modules. Those misaligned modules exhibited a 1.8‑fold increase in post‑release defects compared with aligned modules.
• Code Ownership Clash was observed in 12 % of the source files, with an average of 4.3 edits per file by distinct developers within the study period. These files showed a statistically significant rise in change‑set size and bug‑fix effort.
• Project Coordination Clash manifested as a 35 % divergence between the manager‑defined task order and the actual commit order, correlating with an average schedule delay of three weeks per project.

TESNA’s dashboard visualises each clash using colour‑coded icons and provides drill‑down capabilities so managers can answer “who edited what, when, and why.” The tool also issues pattern‑based alerts when a clash exceeds a predefined risk threshold, enabling proactive corrective actions such as reorganising team boundaries, assigning explicit code owners, or revising the project plan.

The authors acknowledge several limitations. TESNA’s accuracy depends on the completeness and quality of repository logs; informal, face‑to‑face interactions remain invisible. The predefined patterns may not capture domain‑specific coordination nuances, and the sliding‑window parameter may need tuning for faster or slower development cycles.

Future work is outlined as follows: integrating machine‑learning anomaly detection to automatically learn new STSC patterns, extending the tool to ingest additional communication channels (e.g., issue‑tracker comments, video‑conference transcripts), and developing a library of customizable patterns for different organisational cultures. The ultimate goal is to evolve TESNA into a real‑time, predictive coordination assistant that helps teams maintain alignment between their social structures and technical architectures, thereby improving software quality and project predictability.

In summary, the paper demonstrates that by mining existing software‑engineering artefacts and applying a rigorous socio‑technical analysis, it is possible to surface hidden coordination problems early, validate them against well‑known patterns, and provide actionable insights to project managers. The empirical evidence from a corporate environment confirms that TESNA can reliably detect Conway’s Law, code‑ownership, and coordination clashes, supporting its claim as a valuable addition to the toolbox of modern software project management.