The first week of January has a particular feel to it. The inbox is quiet, half the team is still drifting back from leave, and nobody has started the project that will define the quarter. It is a rare pocket of calm, and it is the best chance you will get all year to look at the codebase itself rather than the tickets piled on top of it.

A health check is not a rewrite, and it is not a sprint spent tidying things nobody will notice. It is a short, deliberate pass over the parts of a system that decay quietly: dependencies, tests, documentation and security. A few focused days now will save you several unpleasant ones in October.

Begin with dependencies, not the backlog

Your backlog will still be there in February. Your dependency tree, though, keeps moving whether you watch it or not. Generating the list takes minutes: npm outdated, pip list --outdated, bundle outdated, dotnet list package --outdated, or the equivalent plugin for your build tool. What matters is what you do with the output.

Sort everything into four buckets and resist the urge to work through them alphabetically:

• Safe updates. Patch and minor versions where your test suite already passes. Merge these this week and stop thinking about them.
• Majors that need reading. Check the changelog and migration guide, then book a short spike. Upgrading one library deliberately is far cheaper than upgrading six in a panic.
• Unmaintained packages. No release in years, unresolved advisories, or a single maintainer who has clearly moved on. Find a replacement, or accept the risk in writing.
• Unused packages. If nothing imports it, delete it. Every dependency you remove is one you never have to patch again.

While you are in there, check licences. A package that changed licence terms between versions can create a problem that nobody notices until a legal review before a big contract. It is also worth hunting for duplication: three date libraries and two HTTP clients in one service is a maintenance tax with no upside.

Test coverage: use it as a map, not a score

A coverage percentage on its own tells you very little. A project can sit at 85 per cent and still have no test covering the code that deletes customer records. The number is useful as a diagnostic, not as a target to defend in a stand-up.

A better question is: which files changed most over the past year, and what is the coverage there? Combine your last twelve months of commit history with the coverage report from your CI run. The files with high churn and low coverage are where your next incident is most likely to come from, and they are usually a short list.

Deal with flaky tests before adding new ones

A flaky test is worse than no test at all, because it teaches the team that a red build might mean nothing. Find the tests that fail intermittently, tag them, and give someone a deadline: fix them, rewrite them, or delete them. A suite that takes forty minutes to run is a second problem; if nobody runs it locally, the first feedback a developer gets is a failed pipeline twenty minutes after they push.

Documentation that actually gets read

The useful test is simple. Ask someone who joined recently to follow your README from a clean machine to a passing test run, without asking anyone for help. Note every point where they hesitate. That list is your documentation work for January.

In practice, the pages worth keeping are:

• A README that covers local setup, required environment variables and how to run the tests.
• Runbooks for the handful of alerts that page someone at three in the morning.
• Short, dated architecture decision records explaining why the odd-looking choices were made.

Everything else should be reviewed and, in many cases, deleted. A stale wiki page that describes a service you retired two years ago is worse than an empty one, because people trust it.

Security patches, secrets and access

Agree, in writing, how quickly different classes of vulnerability get fixed. Critical issues in internet-facing systems should be measured in days. Everything else needs a realistic cadence, because a policy that says "immediately" for everything is a policy nobody follows. Dependency alerts are only useful if a named person owns the queue; an unread alert feed is just background noise.

Secrets and credentials

Search your repository history, not just the current code, for keys and tokens that were committed at some point and then removed. Assume anything that ever reached a remote has leaked, and rotate it. Do the same for credentials pasted into chat threads. Enable two-factor authentication on your package registry and your source host, and check that CI tokens are scoped to what they actually need rather than defaulting to write access on production.

Containers, base images and backups

Rebuild container images on a schedule even when application code has not changed, so base image patches actually reach production. Then test a restore from backup. An untested backup is a hope, not a plan. If you handle regulated or personal data, treat this section as a starting point and speak to whoever owns compliance in your organisation about your specific obligations.

Pipeline and repository hygiene

Look at build times and caching, because a slow pipeline quietly changes behaviour: people batch changes, review them less carefully and avoid small commits. Check that third-party CI actions are pinned to versions rather than branches, so a compromised upstream release cannot run in your environment.

Then clear out dead weight. Feature flags that have been at 100 per cent for six months are not flags any more, they are just branches with extra steps. Delete the disabled code path. Remove commented-out blocks, unused configuration keys and alert rules pointing at services you no longer run. Small removals compound; a codebase that is easy to read is easier to change.

Turn the checklist into a calendar

Do not attempt all of this in one heroic week. Split it across the quiet part of January and give each item a name next to it, because "the team" will not do it and a person might.

1. Day one: dependency audit, safe updates merged, spikes booked.
2. Day two: coverage review on high-churn files, flaky tests quarantined.
3. Half a day: README and runbook pass with a recent joiner.
4. Half a day: secrets rotation, access review, backup restore test.
5. An hour: write the recurring items into the calendar.

That last step is the one that keeps the work from being repeated next January. Put a monthly dependency day in the diary, a quarterly secrets review, and an annual deep check. Keep the list in the repository as a plain file, so it survives the departure of whoever wrote it.

Maintenance is not the opposite of feature work. It is what keeps the next feature cheap.

Photo: RDNE Stock project / Pexels