Our Zero Dead Code Rule and Why Unused Code Is a Liability

Many codebases carry a quiet burden: functions nobody calls, settings nobody reads, components that were "added for later." Each one looked harmless when it was written. Together they make a system harder to understand, harder to secure and slower to change.

At Jag Journey we follow a simple rule we call Zero Dead Code. Anything new that we add, whether a function, a command, an endpoint, a data type or an interface component, must be fully integrated and actually used in the same piece of work. A new warning about unused code is treated as an error, not as a note for someday.

What counts as dead code

Dead code is anything that exists in the codebase but has no path to being used. Common examples include:

• A helper method written "in case we need it" that nothing calls
• An API endpoint that is registered but never reached by any screen or integration
• A configuration option that no code reads
• A form field that saves a value nothing ever uses
• A component built for a future screen that does not exist yet

The last two are the sneakiest, because they look like features. A customer can fill in a field and believe it does something.

Why unused code is a liability

It is tempting to think unused code costs nothing. In reality it costs in at least four ways.

It must still be read. Every developer and every AI assistant that touches the area has to understand it, decide whether it matters and work around it.

It must still be secured. An endpoint that "nobody uses" is still reachable. If it lacks the permission checks that live code has, it becomes an opening.

It misleads. When a setting exists, people assume it works. When a function exists, people assume it is correct. Unused code is untested by real use, so those assumptions are often wrong.

It blocks change. Renaming or reshaping a shared concept means updating every reference, including the ones that do nothing.

How the rule changes the way we plan work

Zero Dead Code is not about deleting things aggressively. It is about finishing what we start. If a piece of work introduces a new service, the same work must connect it to the screen, the job or the integration that uses it. If that connection is too big to finish now, the service waits until it can be connected.

This pushes us toward smaller, complete slices. Instead of building a whole data layer first and the screens later, we build one path from the screen down to the database and back, working end to end. Then we build the next one. Each slice is useful the day it ships.

Finding dead code that already exists

The rule also guides cleanup. When we discover a field that saves data nothing reads, or a section of a settings page that has no effect, we either wire it up properly or remove it.

A recent example: our blog editor let authors add FAQ entries and choose a structured data type for a post, but the public page did not use either. Rather than leave a misleading option in place, we connected it, so the questions an author enters now become FAQ markup that search engines and AI assistants can read. The field finally does what it promises.

Tools help, but judgment decides

Static analysis tools can flag unused imports, unreachable branches and private methods that nothing calls. We pay attention to those warnings. But tools cannot tell you that a public setting is never read or that a database column is written and never displayed. That takes a person asking, "Who uses this?"

We ask that question during review. If nobody can answer it, the code does not merge.

The payoff

A codebase without dead weight is easier to trust. When something exists, it is there for a reason, and someone can point to where it is used. That makes our software faster to change for the customers who depend on it, which you can read more about on our Technology & Impact page. It pairs naturally with our habit of reading the existing code first: together they keep the platform small enough to understand.

Frequently asked questions

Does Zero Dead Code mean you never plan ahead?

No. We plan ahead in documents and roadmaps, not in unused code. When the future feature is ready to build, the code arrives together with the screens and integrations that use it.

What about code kept for old customers or legacy links?

Code that serves real existing customers or keeps old links working is in use, so it is not dead. The rule targets code with no path to being used at all.

How do you handle a warning about unused code during a deadline?

We fix it in the same piece of work, either by connecting the code or removing it. Shipping with the warning would simply move the cost to the next person.