Why We Read the Existing Code Before Writing a Single Line

Every software team eventually faces the same temptation. A request comes in, the solution seems obvious, and it feels faster to write something fresh than to dig through code someone else wrote. At Jag Journey we have learned to resist that pull. Before anyone builds a new feature, they read what is already there.

That sounds slow. In practice it is the opposite, and the reasons say a lot about how we build software.

A large platform hides a lot of finished work

Our platform, VoVo, is made of many modules that share one login and one database: websites, membership, email, a shop, courses, events, support and more. Each module has its own services, settings pages and background jobs. When a module grows for years, it accumulates answers to problems nobody remembers solving.

A payment flow already knows how to read each customer's payment settings. A media library already removes duplicate uploads. A settings service already knows which value wins when the database, the environment and the default configuration disagree. If a developer skips the reading step, they will likely rebuild one of those answers, slightly differently, and now the platform has two.

Two versions of the same idea are worse than one. They drift apart. Bugs get fixed in one and not the other. Customers see different behavior depending on which screen they use.

What "reading first" looks like in practice

Reading first is not a vague instruction to "be careful." It is a short, repeatable routine:

1. Search the modules for the concept. If the request is about payments, look at the payment module first. If it is about files, look at the media library.
2. Open the module's service provider and configuration. These files show what the module registers, what it exposes and what can be configured.
3. Find the admin settings that control the behavior. Many questions are already answered by a setting a customer can change.
4. Read the services that do the real work. These are the classes other code is supposed to call.
5. Only then decide what is missing. Sometimes the answer is a small extension. Sometimes it is nothing at all.

We keep a written standards document that lists our modules and the shared services every new feature must use. It is the first stop for anyone, human or AI assistant, before code is written.

Reuse protects customers, not just developers

It is easy to frame this as a developer productivity habit. The bigger benefit is to the people who use our software.

When every payment goes through the same orchestrator, a customer's payment settings apply everywhere. When every upload goes into the same media library, a customer can find every file they ever added in one place. When every feature checks the same permission system, an administrator who removes someone's access knows it is removed everywhere.

Consistency is a promise. Parallel implementations quietly break it.

The cost of skipping it

We have seen what happens when the step is skipped, and the pattern is always similar. A feature ships quickly. Weeks later someone notices it ignores a setting that every other screen respects, or it stores files somewhere the backup system does not know about, or it shows records from the wrong website. The fix then takes longer than the original feature, because now there is data to clean up and behavior to reconcile.

Reading first does not prevent every mistake. It prevents the most expensive category of mistake: building a second system next to one that already works.

How AI assistants change the equation

We use AI coding assistants, and they make this habit more important, not less. An assistant can produce a plausible new service in seconds. It cannot know, unless it is told or it looks, that the platform already has one. That is why our written instructions direct every assistant to check the existing modules and shared services before writing new code, and why a person reviews the result.

The speed of generating code is no longer the bottleneck. Knowing which code should exist is. You can read more about how we pair people and assistants in our approach to AI-assisted work.

When the answer really is "build something new"

Sometimes the reading step confirms that nothing suitable exists. That is a good outcome too, because now the new work starts with a clear map: which services it should call, which settings it should respect and which patterns it should follow so it feels like part of the same product.

New modules at Jag Journey follow a checklist for exactly that reason. Data belongs to the right customer. Screens follow the shared admin design. Payments use the shared payment path. Nothing is wired halfway.

Frequently asked questions

Does reading existing code first slow down small fixes?

Rarely. For a small fix the reading step often takes a few minutes, and it frequently reveals the real cause of the bug in a shared service rather than in the screen where it appeared.

What if the existing code is poorly written?

Then the right move is usually to improve it in place, so every feature that depends on it benefits. Building a replacement next to it doubles the maintenance and leaves the old problems behind for someone else.

How do new team members learn where everything lives?

We keep a standards document that lists each module, the shared services and the rules for payments, settings and data isolation. It is written for both people and AI assistants, and it is updated when the platform changes.