Which artifacts show co-changes in the example?

Commit and defect data highlight shop modules that change together.

How does a metric become a testable question?

Define the data window, unit, and decision before analysis, then inspect code paths.

What does frequent co-change prove?

It shows statistical coupling in recorded changes, not causation by itself.

Standalone conceptMethodChapter III · Evolution · Building block 8 of 15

Software Analytics

Change risks and coupling patterns are hard to see across development data.

By Michael Meierhoff · Meierhoff Systems

DataData: Repository and runtime traces provide the evidence.
PatternPattern: Linked changes reveal hotspots and coupling.
DecisionDecision: Findings are prioritized in context.

Context

Why this is important

Turn development data into reviewable architecture questions.

Shop example · Mapping

Software Analytics: inspect the decision

The shop example uses the existing shared database and seven modules. Any added service or deployment model is a hypothetical extension. A team observes that order and payment code often change together and appear in defects across several releases. Software analytics links commit history, module ownership, and defect tickets into a hotspot report. A review finds that a shared pricing rule explains the coupling; the metric alone would not reveal the cause. The team prioritizes a clear contract and tracks change effort and defect rate over subsequent releases.

This is how you read the picture

Data Data
Pattern Pattern
Decision Decision

Software Analytics: inspect the decision
Concept	Meaning	Review question
Data	Repository and runtime traces provide the evidence.	Which artifacts show co-changes in the example?
Pattern	Linked changes reveal hotspots and coupling.	How does a metric become a testable question?
Decision	Findings are prioritized in context.	What does frequent co-change prove?

Hotspots, Änderungskopplung, Churn und Fehlerhäufungen lenken Aufmerksamkeit auf prüfenswerte Bereiche. Kennzahlen beschreiben Indikatoren, keine Ursachen oder Architekturqualität an sich; Interpretation braucht Zeitbezug, Domänenwissen und Gegenprüfung im System. Use the questions in the second column to test this scenario.

Benefits & limitations

Helps if:

Turn development data into reviewable architecture questions.
Define the measurement question, data window, and decision before selecting a metric.

Boundaries

A correlation in repository data does not prove a technical cause.
Repository metrics cover only observed artifacts and may miss teams, rationale, or production impact.

In practice

Choose a period covering several shop releases and check whether co-changes in order and payment code are consistently visible in commit and defect data.
Map observed coupling to the seven existing modules and ask an architecture review to check domain causes such as shared transaction boundaries or duplicated rules.
Turn a confirmed pattern into a testable hypothesis and compare later releases; treat correlation as a clue, not proof of cause.

Read the detailed explanation

Software analytics collects and connects data from code, version control, issue tracking, builds, and runtime to answer questions about a system’s development and use.

Hotspots, change coupling, churn, and defect clusters direct attention to areas worth investigating. Metrics are indicators, not causes or architecture quality by themselves; interpretation requires time context, domain knowledge, and validation in the system.

Check your understanding

Test yourself in three stages

ReadingCheck in the picture
Which artifacts show co-changes in the example?
View the solution with justification
Commit and defect data highlight shop modules that change together.
ApplyingTransferred to a new situation
How does a metric become a testable question?
View the solution with justification
Define the data window, unit, and decision before analysis, then inspect code paths.
EvaluateWeighing an alternative
What does frequent co-change prove?
View the solution with justification
It shows statistical coupling in recorded changes, not causation by itself.

Explore further

Find variants and links to standalone concepts here.

Hotspots

A hotspot is an area where changes, defects, or effort cluster. Teams use it to choose a concrete review question; high activity alone proves neither poor quality nor the cause of a defect.

Change coupling

Change coupling occurs when separate files or modules repeatedly change together. It helps identify candidate architecture boundaries, but must be checked against code ownership and business collaboration.

References

Continue on the learning path

Next in Evolution & assessment: Architecture erosion.

15 Building blocks

Continue withArchitecture erosion