Development activity
Is engineering building the future — or keeping the past alive?
CodeDD reads git history across the estate — every repository in scope — to show how much effort goes into new product versus maintenance, and which critical systems have gone quiet.
38%
New product work
62%
Maintenance
3
Engineers on legacy code
| Repository | Lifecycle | New work · maintenance |
|---|---|---|
| legacy-etl | Legacy | |
| billing-api | Active | |
| reports-svc | Active |
Trusted by
Beyond a commit chart
Activity is not investment.
A busy team can still be spending most of its time keeping old systems running. The question is where the capacity goes.
New product or upkeep
Every commit is classified as new work or maintenance, so you see the real split of engineering capacity.
The cost of legacy
How many engineers still work on legacy systems, and whether they are extending them or just keeping them alive.
What has gone quiet
Business-critical repositories with no recent commits — the systems nobody is looking after.
Where to look first
Critical systems that have gone quiet.
Business impact against last commit puts important repositories that nobody touches in one corner. That is where risk builds without anyone noticing.
The legacy question
Keep it running, or move off it?
Who still works on legacy repositories, and on what. Mostly maintenance is ongoing drag; new features on old ground are a migration decision waiting to be made.
Active
Dormant
Stale
High impact
billing-api · legacy-etl—pricing-engineLower
reports-svcdocs-site—pricing-engine: business-critical, no commits in over six months.
legacy-etl · 3 engineers this quarter
Mostly keeping it running. One person is still building new features on it.
| Engineer | Area | Their work |
|---|---|---|
| Maya Chen | Data | 80% maintenance |
| Sam Okafor | Billing | 70% maintenance |
| Priya Shah | Platform | 55% new features |
CodeDD Advisor
Ask where the risk hides
The Advisor crosses activity with business impact and known vulnerabilities — the combinations no single dashboard shows.
Across the investment cycle
Where it changes the plan
Pre-deal tech DD
Know how much of the team you are buying is available for growth, and how much is tied up in upkeep.
Hold period
Shift capacity from maintenance to the value-creation plan, and show the split moving quarter by quarter.
Pre-sale preparation
Show a buyer an engineering team that builds, with legacy systems retired or deliberately contained.
FAQ
Questions
How do you decide new work versus maintenance?
Commits are classified from git signals — messages and the type of change — into new work (features) and maintenance (fixes, chores, upgrades, docs, CI). It is a consistent heuristic across the estate, not a timesheet: use it for the shape of the team's effort, not for a performance review.
What counts as legacy?
A lifecycle label on each repository — the older lines, as opposed to active product. Filter to legacy and read the mix on those repositories to answer whether the company is still building on the old stack or only keeping it alive.
How is this different from Team & key-person risk?
This page shows where effort goes and what has gone quiet. Team & key-person risk shows who holds the knowledge — how concentrated ownership is, and whether each area has enough people.
How is this different from Delivery (DORA)?
Delivery measures how often and how safely the team ships. This page measures what that effort is spent on. A team can ship smoothly and still spend most of its time on maintenance.
Are bots included?
Bot accounts can be hidden, and the default view shows people. Cross-repository views ignore bots, so a CI account never looks like your most connected engineer.
What data do you store?
Git analytics — authors, dates, repositories, areas, and the classification of each commit. Not source code.
See where engineering effort goes in a team you are evaluating
Run it on your repositories yourself, or book a walkthrough of the split, the legacy systems, and what has gone quiet.