By Glue Team
Your engineers create the same ticket twice. Different teams, different PRs, different solutions. "Fix payment retry logic" appears twice. One PR handles exponential backoff. The other handles circuit breaker patterns. Both ship. Now you have two ways of solving the same problem.
This isn't laziness. It's a symptom of a broken system.
Why Duplicates Happen
Engineers don't have visibility into what code already exists. They search the issue tracker but don't find related issues (search is poor). They don't know that someone already solved this problem three services over. So they start from scratch.
The root cause: work tracking (tickets) and code understanding (codebase) aren't connected.
Your issue tracker doesn't see your codebase. Your codebase doesn't inform your roadmap. They operate in parallel.
The Cost of Duplication
Wasted effort. Two teams solving the same problem. Hundreds of hours of engineering time.
Merge conflicts. Both solutions need to be integrated. Which one is right? Do you combine them? Keep one?
Technical debt. Two different solutions to the same problem in different places. Now you maintain two patterns.
Maintenance burden. Same fix needs to be applied in two places. Future engineers are confused about which one to use.
Cultural cost. Engineers feel like their work is wasted. Morale drops.
The Real Problem
Your issue tracker can't see your code. When an engineer opens a new ticket for "Fix payment retry," the system doesn't show:
Existing payment retry code. Who maintains it. How it works. What it handles.
Related tickets. Other tickets about payment retry.
Related PRs. Recent changes to payment retry logic.
Without this context, the engineer starts fresh.
The Solution
Connect work tracking to code understanding:
When creating a ticket: Check if similar code exists. Show related code before the engineer starts.
When assigning work: Show the related code and similar implementations. Link to the PR that introduced that code.
When reviewing PRs: Flag potential duplicates. "We already have this pattern here and here."
When closing tickets: Link to the actual code change. Create a record: "This ticket was resolved by this PR in this service."
With visibility, duplicates decrease dramatically. Engineers see what already exists before they start building.
Using Glue to Prevent Duplication
Glue connects your codebase to your work:
When you create a ticket for "Fix payment retry," Glue shows existing payment retry logic in your services. You see the code. You see who maintains it.
Engineers see the related code before starting. Different team members can see what others implemented.
Duplicates are caught before merge. Glue flags potential duplication during code review.
You build once, understand everywhere.
Getting Started
- When a ticket is created, ask: "Does this already exist in our code?"
- Search your codebase for similar patterns
- Link the ticket to related code
- Engineers see the connection before starting
- Duplication decreases
This doesn't require changing your tools. It requires connecting them.
Frequently Asked Questions
Are duplicate tickets ever good? Rarely. Multiple independent solutions to the same problem always create maintenance burden. Better to refactor one solution or consolidate into a shared library than maintain two patterns.
How do we find existing duplicates? Search your issue tracker and codebase for similar terms. Look for code that solves the same problem in different ways. Consolidate where possible.