Understanding Calyntro Analyses
Calyntro offers a comprehensive suite of analyses to help you understand the health, evolution, and risks within your codebase. Each analysis provides a unique lens, from identifying high-activity areas to pinpointing technical debt and knowledge bottlenecks.
As a Lead Developer or Software Architect, you can use these metrics to guide your refactoring efforts, balance team workloads, and mitigate risks before they lead to production issues.
Analysis Scopes
Calyntro allows you to view metrics at different levels of granularity, depending on the questions you are trying to answer:
File Level: Focuses on individual source code files. Ideal for identifying specific “hotspots” or complex files that need immediate refactoring.
Module Level: Aggregates data by logical components or directories. Useful for seeing which parts of the system are growing fastest or where architectural complexity is accumulating.
Team Level: Analyzes how different teams contribute to the codebase. Helps in understanding ownership distribution and identifying potential communication overhead or knowledge silos.
Evolution & Pulse (Activity)
These metrics focus on the “pulse” of your development process—where work is happening and how the codebase is changing over time.
Change Frequency (Commits)
UI Name: Change Frequency / Module Change Frequency / Gesamt Commits
What it Measures: The total number of commits made to a file or module within the selected timeframe. On the Dashboard, it shows the absolute number of commits and the growth compared to the previous week.
How to Interpret: High commit counts indicate active development. A file with an unusually high number of commits compared to others might be a “god object” or a source of instability that requires frequent fixes. Positive growth indicates increasing activity.
Change Recency (Activity Recency)
UI Name: Change Recency / Codebase Age
What it Measures: The time elapsed since a file (or the latest file in a module) was last modified. On the Dashboard, “Codebase Age” represents the average age across the entire codebase or selected module.
How to Interpret:
Young files are recent additions, often indicating new features.
Old files that haven’t been touched in a long time are stable (or dead) code.
Old files with recent changes are often core legacy components that are being maintained.
Increasing Codebase Age suggests a maturing system, while a sudden drop indicates significant new development.
Absolute Churn
UI Name: Absolute Churn
What it Measures: The total number of lines added and deleted. Unlike net Lines of Code, churn measures the volume of activity.
How to Interpret: High churn indicates a file is being heavily reworked. While high churn is normal during initial development, persistent high churn in an established file is a strong warning sign of instability or unclear requirements.
Development Trend (Development Velocity)
UI Name: Development Trend
What it Measures: This compares a “Baseline” period with a “Current” period to show the direction of activity.
How to Interpret:
Spiking: Activity is significantly higher than in the past.
Cooling: The component is stabilizing; activity is decreasing.
Stable: No significant change in activity levels.
Quality & Risk
These analyses combine multiple metrics to identify structural risks and architectural hotspots.
Hotspot Analysis (File & Module)
UI Name: Hotspot Analysis (Zeitfenster) / Module Hotspot Trend
What it Measures: This analysis identifies areas that are likely to cause problems by combining Churn (how much it changes) with Age (how long it has been changing). It compares two time windows to see if a component is heating up or cooling down.
Activity Score: High churn in a short time (current intensity).
Structural Score: Consistent churn over a long period (long-term instability).
How to Interpret:
File Level: Files with both high Activity and high Structural scores are your most critical hotspots. They are likely sources of long-term technical debt and should be the first candidates for refactoring.
Module Level: Aggregates these scores for whole components. It reveals which architectural modules are becoming increasingly unstable over time, helping in higher-level resource allocation.
Structure & Logic (Complexity)
These metrics focus on how difficult the code is to understand and maintain.
Complexity
UI Name: Complexity / Maintainability
What it Measures: A holistic view of complexity, combining:
Cyclomatic Complexity: The number of independent paths through the code (branching logic).
Cognitive Complexity: How difficult the code is for a human to read and understand.
Efforts: An estimated measure of the effort required to maintain the file (based on Halstead metrics).
On the Dashboard, “Maintainability” is derived from these complexity scores. A lower average cognitive complexity indicates better maintainability.
How to Interpret: High complexity scores, especially when combined with high churn (Hotspots), are the single best predictor of bugs. Falling maintainability (rising complexity) on the dashboard is a sign that the code is becoming harder to work with.
Complexity Trend
What it Measures: Complexity isn’t just a snapshot; Calyntro tracks how Cognitive Complexity changes between two points in time.
Calculation: It compares the complexity at the start and end of your selected timeframe.
A relative increase in cognitive complexity suggests that new features are being added in a way that makes the code harder to understand.
A decrease usually indicates successful refactoring or simplification.
How to Interpret: In the UI, icons indicate the trend (Rising, Stable, or Falling). A rising complexity trend in a file that already has high churn is a “code red” situation.
Team & Knowledge (Ownership)
Understanding who knows what is critical for maintaining a healthy project and reducing the “bus factor.”
Code Ownership
UI Name: Code Ownership
What it Measures: Identifies the primary contributor to a file or module and the percentage of their contribution.
How to Interpret: High ownership by a single person is efficient but risky. If that person leaves, knowledge is lost.
Knowledge Fragmentation
UI Name: Knowledge Fragmentation
What it Measures: The number of distinct developers who have modified a component.
How to Interpret: Too many contributors (fragmentation) often leads to a “diffusion of responsibility” and higher communication overhead. It may indicate that a component lacks a clear owner or is a “junk drawer” for unrelated changes.
Knowledge Silos
UI Name: Wissenssilos / Knowledge Risk
What it Measures: Identifies files and modules where a single developer is responsible for an overwhelming share of commits — making that person the sole knowledge holder. A file is classified as a silo when one developer’s contribution meets or exceeds a configurable ownership threshold (default: 80 %). Files with very few total commits are excluded to filter out noise.
On the Dashboard, “Knowledge Risk” reflects the number of identified silos and the “Silo Ratio” (percentage of files within a module that are silos).
Risk Levels: Each silo entry carries a risk classification based on ownership concentration:
Low (80–89 %): One clear owner, but some secondary knowledge exists.
Medium (90–94 %): Near-exclusive ownership — onboarding a second contributor is advisable.
High (95–99 %): Essentially a single point of failure.
Critical (100 %): Absolute sole ownership — no other developer has ever touched this file.
How to Interpret:
File view: Lists every silo file sorted by ownership percentage. Use this to find the individual files with the highest Bus Factor risk and identify which developers carry the most concentrated knowledge.
Module view: Shows the fraction of silo files within each component (
silo_ratio). A module with a high silo ratio indicates a structural knowledge risk even if no single file is catastrophic by itself.Dashboard view: A high Knowledge Risk or a rising Silo Ratio trend suggests that knowledge is becoming increasingly centralized, raising the project’s Bus Factor.
Combining with Code Ownership and Hotspot data: A silo file that is also a hotspot (high churn + high complexity) is the most dangerous combination — difficult code that only one person understands.
Recommended Actions: For critical silos, schedule a knowledge transfer session (pair programming, documentation sprint) before the key developer transitions off the team.
Module Ownership by Teams
UI Name: Module Ownership by Teams
What it Measures: Shows the top modules a specific Team is working on, based on the percentage of churn they generated.
How to Interpret: This view is “Team-centric.” It helps managers see if a team is focused on its assigned modules or if its effort is scattered across the system.
Top Team Contributors
UI Name: Top Team Contributors
What it Measures: Shows the top 3 contributing teams for each Module.
How to Interpret: This view is “Module-centric.” It reveals which teams are actually driving the development of a specific component and identifies cases where a module is being modified by teams that shouldn’t normally be touching it.
Base Metrics
Fundamental statistics about the size and structure of your codebase.
Lines of Code (LOC)
UI Name: Lines of Code
What it Measures: The physical number of lines (net).
How to Interpret: Useful for identifying “God Objects”—massive files that do too much and should be split up to follow the Single Responsibility Principle.
Visual Analysis Views (Module Scope)
The following four views are available when the Module scope is active. They operate on the same underlying data as the table analyses but present it in ways that make structural patterns and trends immediately visible. Because they aggregate across the whole module landscape, selecting a specific analysis type in the sidebar has no effect while one of these views is open — switch back to the Table view to change the analysis dimension.
Code Map
UI Name: Code Map — Risk & Size per Module
What it Shows: A treemap in which every cell represents one module. Cell area encodes Lines of Code; cell colour encodes composite risk.
Risk Formula:
Risk Score = 0.6 × normalised(Cognitive Complexity) + 0.4 × normalised(Absolute Churn)Both inputs are min-max normalised across the current module set, so the score is always relative to the worst module in the selected period — not an absolute threshold.
Colour Scale: A four-stop gradient from green (low risk) through yellow and orange to red (critical).
How to Interpret:
A large red cell is the worst-case combination: a high-LOC module that is both cognitively complex and actively churning. It carries the highest maintenance cost and the highest defect probability.
A small red cell signals a compact but disproportionately risky module — often a utility or integration layer that accumulated complexity without growing in size. Do not ignore it because it looks small.
A large green cell is the ideal: substantial code that is stable and well-understood.
Hover over any cell to see the raw values (LOC, Cognitive Complexity, Absolute Churn) and the numeric risk score.
Practical Use: Run this view at the start of a sprint planning cycle to identify which modules deserve architectural attention. Use it alongside the Scatter view to cross-validate findings.
Scatter Analysis — Complexity × Churn Quadrants
UI Name: Complexity × Churn — Hotspot Analysis
What it Shows: A bubble chart with Cognitive Complexity on the X-axis, Absolute Churn on the Y-axis, and bubble size proportional to Code Age (days since first commit). Both axes use a logarithmic scale.
Why logarithmic axes? Complexity and churn values across a real codebase span several orders of magnitude. A linear scale compresses 90 % of modules into a corner and makes the distribution unreadable. Log scaling preserves the relative distances between modules across the full range.
Quadrant Logic: The two dashed reference lines mark the project medians for complexity and churn. Every module falls into one of four quadrants:
Bubble Size (Code Age): Older modules have larger bubbles. A large red bubble is a long-lived module that has accumulated both complexity and instability — a structural liability. A small red bubble is a recently introduced problem that may still be correctable with modest effort.
How to Interpret:
Focus first on the top-right red cluster. These modules will predictably contribute a disproportionate share of defects and are the primary candidates for refactoring or architectural decomposition.
A purple module with a large bubble (old, complex, quiet) is a latent risk. If it appears in the Warnings list as a “Complexity Spike” in the future, escalate immediately.
If most modules are in the green quadrant with a few isolated red outliers, the codebase is generally healthy with identifiable hotspots — a manageable situation.
A broadly scattered red population indicates systemic complexity growth, not isolated incidents. This warrants a discussion about architectural governance, not just individual file refactoring.
Trend Analysis — Per-Module Time Series
UI Name: [Metric] per Module over Time
What it Shows: A line or area chart of up to 10 modules across a shared time axis, bucketed in configurable intervals (default: 30 days). Four metrics are available via toggle:
Avg. Cognitive Complexity — is the code getting harder to understand?
Lines of Code — is the module growing, shrinking, or stable?
Silo Ratio — is knowledge becoming more concentrated over time?
Commits — how is development activity distributed across modules and periods?
How to Read the Chart:
Lines that are rising together (complexity + LOC) indicate uncontrolled growth — new functionality is being added without simplification.
Rising Silo Ratio with falling Commits is a particularly dangerous pattern: development is decelerating while knowledge is centralising. The module is drifting toward a single point of failure.
Diverging complexity lines between modules of similar function suggest inconsistent engineering standards and warrant a cross-team review.
Use the bucket size (30-day default) to balance noise and signal. For fast-moving teams, a 14-day bucket reveals sprint-level patterns; a 90-day bucket is better for quarterly architecture reviews.
Module Toggle: All modules are shown by default (up to 10). Deselect modules to reduce visual noise and compare specific candidates side by side. Line colours are stable — toggling a module on and off does not reassign colours.
Dashboard — Warnings
UI Name: Dashboard → Warnings panel
What it Shows: Up to five prioritised warnings derived entirely from Git history — no external integrations required. The backend generates up to ten candidates, ranks them by severity and normalised risk score, and returns the top results.
Warning Types:
Reason Code
Max Severity
Trigger Condition
critical_hotspotCritical
Composite hotspot score ≥ 90 % of the highest score in the period (critical) or ≥ 70 % (high). Score = complexity × churn weighting.
silo_riskCritical
A single developer accounts for ≥ 95 % of commits to a file (critical) or ≥ 80 % (high). Files with fewer than 5 total commits are excluded.
complexity_spikeCritical
Cognitive complexity trend indicator > 4.0× baseline (critical) or > 3.0× (high).
churn_outlierCritical
File churn > 5× the project average (critical) or > 3× (high).
legacy_reactivatedHigh
File age > 365 days and recent churn > 2× project average. Indicates that dormant, complex code is being actively modified.
Risk Score — Critical_Hotspot: The displayed value (e.g., “Risk score 94 / 100”) is a relative score, not an absolute threshold. It is computed as
(module_hotspot_score / max_hotspot_score_in_period) × 100. A score of 94 means this module is 94 % as risky as the worst module currently in scope — not that it has crossed a fixed danger level. Scores will shift as the date range changes.Ranking: Warnings are sorted first by severity (Critical before High), then by normalised risk score descending. This ensures the most actionable items appear at the top regardless of which warning type they belong to.
Navigating from a Warning: The “Details →” link routes to the corresponding analysis view (e.g., a hotspot warning links to the Complexity analysis filtered to that module). Use this as the entry point for root cause investigation.
Recommended Workflow: Review the Warnings panel at the start of each sprint. A warning that persists across multiple consecutive periods without remediation is a strong signal that it has become structural debt — escalate it to the architecture backlog.
Comment Density
UI Name: Comment Density
What it Measures: The ratio of comments to code lines.
How to Interpret: Extremely low density might indicate cryptic code; extremely high density might indicate that the code is so complex it requires excessive explanation, or simply contains a lot of “dead” commented-out code.