• Code Quality and Scale of Dependencies Between Teams

  Jul 25, 2025

  Building software is hard. Building maintainable software is harder. Building maintainable software in an organization with a lot of teams that depends on a lot of other teams is even harder.

  As someone who prides in code quality and who mentors teams in producing high quality code, I have been frustrated for years by the difficulties in consistently producing quality code by my teams. Recently, I have been observing my team wrestle with a long-running feature that required a lot of coordinating between my team and its upstream and downstream dependent teams. The coordination effort was necessary because the API contract between the teams needed to change as each team discovered how each property in the contract is used.

  Simultaneously, my team was also attempting to improve its test quality by implementing application service tests. These tests intentionally capture the interaction between our service and its dependencies. As a result, the tests’ churn reflected the churn in the API contract.

  Seeing the code and test changes caused by the coordination efforts, I realized the importance of high quality work and how the importance is correlated with the number of dependent teams. Which is to say, the team that depends on five teams would benefit far more with high quality work than the team that only depends on one other team.

  This may be simply me connecting my experience to what I have learned by reading Extreme Programming Explained, which is one of the most influential books I have read. In the book, and writings and talks shared by many prominent XP practitioners, change is the one constant in software development. And the most reasonable way to handle change is by adopting habits that embrace this reality. High quality work is paramount in this context. Low quality work inhibit the agility in responding to change.

  In this context, team dependencies can be viewed as potential sources causing team change. It is far more likely for a team that depends on seven other teams to get requests for change compared to a team that depends on one or two other teams. The best way to handle the changes is to have high quality work. Unfortunately, as the number of dependencies increase, it also becomes harder to perform high quality work, since it takes time to learn the skills and techniques needed to design around dependencies and their complexities. In other words, high dependencies between teams is a double whammy: it demands high quality work but it also makes high quality work harder.

subscribe via RSS