How Conway’s Law Shapes QA: Lessons from JD.com’s Automation Testing Revamp

Introduction

The author reflects on the automation testing system built at JD.com, focusing on recurring QA challenges and the need for a higher‑level perspective to locate and solve problems effectively.

Conway’s Law and Organizational Structure

Conway’s Law states that a system’s architecture mirrors the communication structure of the organization that creates it. The article illustrates this with diagrams and explains four derived principles: communication shapes design, time constraints, alignment between linear systems and organizations, and the tendency of large systems to decompose.

Examples from nature (tree structures) and software development (micro‑services, DevOps) show how aligning team structures with system design reduces friction.

Organizational Culture

Team cohesion, trust, and shared purpose are essential. The author argues that stable, long‑lived teams outperform project‑based ad‑hoc groups, recommending that teams be kept intact across multiple projects and that leadership invest time (6‑12 months) to build cohesion.

Key cultural factors include recognizing bottlenecks, shortening delivery cycles, accurate forecasting, aligning goals, standardizing processes (e.g., Agile), and strengthening technical foundations (CI/CD, tooling).

Practical Case: Coupon System Refactor

JD.com’s coupon platform suffered from a “vertical silo” architecture, causing data‑structure sprawl, duplicated services, and rising defect rates. A three‑person team supported the legacy system, leading to uncontrolled growth.

To address this, the organization split the business and technical sides: each business unit (growth, retention) formed its own development team, while core coupon lifecycle functions were centralized into a middle‑platform service. This reduced multi‑to‑one coordination costs and improved efficiency.

However, the testing team was not re‑aligned, causing a temporary dip in test quality. The subsequent re‑mapping of testing resources restored the end‑to‑end delivery chain.

Problem Recognition and Quality Metrics

The article defines high‑quality delivery as low defect count and high throughput, measured by bugs per thousand lines of code and story points delivered per iteration. Tools like Jira are suggested for tracking.

When third‑party tools fall short, building custom CI/CD solutions is recommended.

Estimating Effort with Probabilistic Models

Using the Six Degrees of Separation analogy, the author advocates asking “why” repeatedly to uncover root causes. For effort estimation, the PERT three‑point technique (Optimistic, Nominal, Pessimistic) is explained, with formulas for expected duration μ = (O + 4N + P) / 6 and standard deviation σ = (P – O) / 6.

Aggregating multiple tasks involves summing expected values and combining variances (σ_total = sqrt(∑σ_i²)). This provides a more realistic confidence interval than single‑point guesses.

Conclusion

The piece ties together Conway’s Law, team culture, and quantitative estimation to propose a systematic approach for improving software delivery quality. By aligning organizational structures with system design, fostering cohesive teams, and applying probabilistic planning, organizations can build resilient “special‑force” teams capable of delivering reliable products.