Change Over Time

See the evolution of activity across your codebase

Change Over Time

I remember building a calendar component for a language school. The calendar was very simple at the beginning: it displayed lessons or free days. Over time, new requirements kept arriving: holidays, substitutions, multiple lessons per day, postponements, and more. Each one seemed small and reasonable on its own.

All of this growing complexity eventually ended up in a single file: the calendar data provider. Every time a new requirement appeared, it was simply added there.

As you can imagine, the calendar data provider quickly became a nightmare to maintain. Every change risked breaking something else. A spoiler alert, it often did. Whenever the client sent an email, I secretly hoped it wasn't about the calendar.

I personally call this phenomenon “don't waste time on refactoring, just one more feature and we're done”. In reality, it usually means the feature is highly successful and therefore keeps growing without ever truly being finished.

Why it matters

Looking at how your code changes over time shows you patterns you can't see any other way. Stable code barely changes from month to month. Stable code just works and nobody needs to touch it. Churning code shows constant activity, which might mean it's growing fast or struggling with design problems.

When you see a sudden spike in changes, something important happened. It can be a new feature, a major refactoring, or a crisis fix. Tracking these patterns over weeks and months helps you understand which parts of your system are solid and which parts are falling apart. It's like watching the health of your codebase over time.

Cosmic Analogy

Some of the stars in the galaxy are stable, shining steadily for eons. Others are in a state of rapid evolution, gathering mass and burning brightly. By observing their evolution over time, you can distinguish between a healthy, growing star and one that is becoming unstable and prone to collapse. The same as in your codebase. Some files remain stable and reliable, while others change often, which may signal underlying issues.

Cosmic analogy

Change Over Time Visualization

How to Fix

Detection & Monitoring

Monitor for sudden activity spikes - they signal architectural decay or feature cramming into the wrong places.
Investigate files that transition from stable to churning - find out what changed and whether it needs restructuring.
Set alerts for files exceeding normal change velocity to catch problems before they become crises.
Review commit patterns monthly to identify trending hotspots and address them proactively.

Analysis & Baselines

Correlate change spikes with feature releases to understand if growth is intentional or accidental.
Establish baseline change rates for different types of code (core vs. feature, backend vs. frontend) to identify anomalies.
Use historical trends to predict which areas will need refactoring in the next quarter.

Action & Planning

When you see consistent high churn, consider splitting the file or extracting responsibilities into new modules.
Plan refactoring sprints when you notice files entering accelerating change patterns.

Visibility & Communication

Create dashboards showing change velocity over time to keep technical debt visible to the team.