When we evaluate an organization's Software Development Life Cycle, we start with code discovery. Not because it's the most important aspect, but because it's the most revealing. A broken code discovery system is the first symptom that signals complete social dysfunction across code, build, test, operate, and analyze phases. It's the organizational equivalent of finding mold in your walls—if you see it on the surface, the infrastructure behind it is already rotting.
What Is Code Discovery, Really?
To understand code discovery, we must first understand the value of code to an enterprise. The best way to grasp this is through a thought experiment.
The Burning Building Scenario
Imagine your company faces catastrophic failure—both physical and digital infrastructure is burning. As a CXO, what do you salvage to maximize value for investors and customers? Let's create a priority list without ethical or moral concerns, purely from a business continuity perspective.
Most employees reflexively say "people" because without people, what would the company do? We've been conditioned to repeat the mantra "we are what our people are." But when layoffs happen, this "people are most important" sentiment rings hollow. People are important, but not the most important—because companies are systems, and systems compete.
Employees are part of systems that create value for customers. But if you let the data center burn—the one currently serving customers—your company dies immediately. So the CXO's first choice is the data center, which includes the code serving customers and the data they depend on.
Second priority? Not people. Consider this: what would the company do with those people if all existing code disappeared? People are valuable because they can work on top of existing code, and existing code is best understood by current people. But given the choice, a CXO should choose code with different people over the same people with no code.
Why? Code represents the accumulated knowledge that developers and technical employees have produced. It's encoded institutional memory. Every new feature, every innovation, every competitive advantage will be built on top of this existing codebase. Whether you have new employees or existing employees, their productivity, quality, and value creation all depend on the existing codebase and how well it's organized.
Any CEO should understand this instinctively: if your people don't know where the code is, how can they build on it?
Code is the most important asset after data centers serving the binaries that come from code. (FYI: code doesn't generally live in production data centers—it lives in version control systems.) If employees build new features on top of existing code, then "Is your code discoverable?" is as legitimate a question as asking a warehouse manager "Is your inventory discoverable?"
The "Yes, But Actually No" Problem
When we ask software companies "Is your code discoverable?" we get universal "yes" answers. Then we investigate and discover that every single "yes" actually means "no."
The problem? Most people don't think in systems. They understand the meaning of the word "discoverable" at a local level in our question, but miss the systemic meaning and implications.
Developer Response
"Yes, it's discoverable. I know all the repos I work on."
This immediately reveals the problem. We asked about the entire company; the developer reduced the scope to their personal repositories. Ask them how many total code repositories exist in the enterprise, and they'll say, "I don't know, but we can figure it out by talking to all the developers."
They're generally wrong about that—they can't figure it out at enterprise level. We'll tell you why soon. But the fact that code discovery requires social engineering and throwing a few project managers at the problem? Code discovery is already broken.
Development Manager Response
"Yes, my developers know—they develop code. But if I need to know more, I can ask other team members. It's all in GitHub."
The fact that you have to ask a human first to locate information is proof that code discovery doesn't exist. Imagine if the CEO asked HR "How many employees do we have?" and HR responded, "I have 15, but for the rest, let's talk to each VP and figure out the list." Absurd, right? Yet we accept this same dysfunction for code repositories.
Executive Response
"Yes, code is discoverable. It's all in GitHub, BitBucket, or GitLab. Our developers work with it; each knows where their code is."
This is where the delusion becomes dangerous. Systems are impossible to fix when everyone believes they're working when they're not. You can't fix a problem you don't understand exists—like how most third-world country members don't understand they're third world. Broken code discovery is the first sign of a broken SDLC.
A Case Study in Collective Delusion
In one Fortune 500 company where everyone believed code was discoverable, a change agent developer issued a challenge: he'd personally put up $10,000 if the company couldn't bring all production code—and only production code—together within five days.
This change agent had credibility and good intent, so the challenge was taken seriously. The confidence of his claim made the CTO pause. In front of his entire staff, the CTO was forced to ask: "Why does he believe code discovery doesn't exist at our enterprise? Why does he think we can't produce production-only code on demand?"
The answer fundamentally changed that organization. The CTO didn't just finally understand the problem—he took a course in Systems Thinking to understand why the change agent could see what others couldn't.
The Tests for Code Discovery
Test 1: Lines of Code Count
Do you know the number of lines of code in your entire SDLC organization? Not a single repo. Not a team. The whole organization.
If you don't know this number, code discovery doesn't exist.
Companies like Google and Facebook—operating at scales thousands of times larger than most enterprises—know not only the exact count of code, but how much each engineer added or removed, along with countless other statistics. These aren't special capabilities requiring exotic tools. When code discovery exists, a few scripts or inexpensive tools can provide this data.
Mini case study: One company entered a four-year, $4 million contract for code metrics tools showing lines of code and metrics like code churn (which we believe are not only wrong but harmful). No one noticed that the combined lines of code across all repositories totaled 4 billion—an impossible number for 2,000 developers. The inflated numbers came from their polluted enterprise GitHub, for reasons we'll discuss below.
Test 2: The Benign Change Test
Consider the Log4j incident. Every Java application needed to upgrade their pom.xml file—changing literally three characters from log4j 1.7.8 to 1.7.9. A purely benign change.
If you need to involve a member of every team to make this benign code change across repositories, you don't have enterprise-level code discovery. Such a change should be executable by a single developer across hundreds of repositories. The fact that you need 200 developers reveals that each knows their own code, but the enterprise as a whole doesn't know where code lives. Otherwise, why ask 200 people to do something one person could do?
Why Code Discovery Breaks: The Polyrepo Catastrophe
In modern organizations, code discovery is primarily broken due to the introduction of the polyrepo model. Let me explain.
Before tools like GitHub entered the scene, most enterprises had one instance of version control management—one repository. Companies like eBay and PayPal used tools like ClearCase, SVN, or VCS. Some companies might have two, three, or at most a few repos—what we now call monorepos.
Today, most people have nothing but distaste for monorepos because of painful experiences with ClearCase, SVN, or early Git. But in retrospect, the distaste was due to monolithic codebases, not the mono-repository structure itself. To escape monolithic code, microservices architecture emerged. GitHub entered the scene, making repository creation a one-click job. Soon enterprises started adopting GitHub Enterprise—private GitHub for companies.
The primary reason enterprises adopted GitHub was simple: developers loved it. But here's what they missed: GitHub was designed for the open-source world, where millions of repositories exist. It was built for polyrepo architecture. When enterprises bought into GitHub during the microservices revolution, they suddenly had thousands of micro repositories.
At the micro-social level—five developers creating a repo for an app, library, or module—this isn't a problem. They know where things are. But at the enterprise level, it creates an invisible fiasco that makes code completely undiscoverable if polyrepo isn't governed properly. And proper governance is social engineering, which most companies completely fail at.
The GitHub Organization Nightmare
Here's what we see in countless companies where social architecture and engineering are absent:
GitHub has a concept called "organizations"—all code repositories live within organizations. Most enterprises hand over GitHub management to a central DevOps team who only understand availability and software updates. Meanwhile, thousands of engineers are given control to do whatever they want.
When developers need to create a repo for their component, service, or library, they have no idea which organization to use. So they create organizations based on their current team name. I worked at a company where the organization was called "Checkout"—developers created a "Checkout" organization in GitHub and filled it with repositories. Similarly, there were organizations called "Ecommerce," "Risk," and "Compliance." Some engineers created organizations named after their team. People created whatever they thought the organization name should be.
Who gets permission to push code? That's also determined locally. If you need push access to a repo, you have to find the admin and negotiate access. Organization counts balloon, each containing multiple repos.
The Naming Catastrophe
Repository names are determined by engineers, who are notorious for cryptic naming. Depending on the current trend, repo names might be:
- Greek gods: Hermes, Aries, Apollo, Olympus
- NASA projects: Challenger, Apollo
- Animals: Tortoise, Giraffe, Hippo
- Historical references: Sparta, Athenian, Panda
- Indian developer centers contributing: Disha (Hindi for "direction"), Vishnu (Indian god)
Production service names are relatively sane—operations teams go bonkers trying to keep them running, so you'll see names like "PaymentProcessingService." But the repo name? "Opera." Good luck mapping that.
For libraries and node modules, this mapping becomes impossible.
The Re-org Multiplication Effect
Re-orgs happen. We're not against re-orgs—we're against not having systems for code management during re-orgs. Every VP during a re-org divides people and production services, but no one divides up code and code ownership.
In one company, the original GitHub organization was "Checkout." Then engineers created a shorthand called "Xi" (not sure why). Half the repos lived in Checkout, half in Xi. A new VP arrived and declared, "We're not customer-focused enough" (which was true), so he changed the organization name to "Customer Experience," creating a new "CE" organization. Then he reconsidered: "It should be Customer Engineering and Experience," spawning yet another "CEE" organization.
Code fragments, and fragments, and fragments.
The Open Source Culture Delusion
Engineers and management don't see this as a problem. They think they're following open source culture, which they believe is the greatest culture that can ever exist.
Another open source practice? Forking. Now thousands of repos have thousands of forks scattered across the enterprise. Combine this with the branching strategy mess (which we've written about separately), and you get an exponentially larger disaster.
Then there are hackathons—hundreds of new repos. Countless failed projects leave abandoned components scattered everywhere. Code discovery is obliterated.
Why No One Admits the Problem
For a simple reason: every engineer believes they know where their repos are, so no developer believes a code discovery problem exists. Management believes GitHub is the best tool and all code is in GitHub, so they're satisfied. Tools like GitPrime show metrics and dashboards, creating a false sense of security: "We must know where the codebase is; otherwise, how would we get this data?"
The Site Operations Perspective
One team that should recognize broken code discovery is site operations. They constantly send emails during incidents: "Who owns this component? Where is the source code?"
But even they miss the systemic problem. They think developers aren't taking responsibility for incident response. There might be some truth to that, but engineers can't all be that negligent. Site Reliability Engineering fails to see that we have a systemic code discovery problem. No developer wants to wake up at 3 AM to tell you which GitHub organization, which fork, which branch contains the source code.
The Cost of Broken Code Discovery
When we discuss broken code discovery, executives ask, "Can you quantify the cost?"
In one company, we quantified the total cost at $15 million. Our solution would cost $1.5 million. The VP of Program Management said, "No one will buy it—not the $1.5 million solution, but the $15 million problem."
So we requantified it as $5 million. In reality, the cost of delayed projects, lost productivity, and other cascading failures far exceeded $15 million.
Broken code discovery should be a CEO or board-level discussion. If your software development factory is this fundamentally broken, then all your strategy—however correct—and all your transformation efforts and behavioral changes will produce terrible results.
Governance vs. Control
The root job of a central SDLC team is to provide governance. Not dictatorial control, but governance. Governance enables people to achieve greatness. It doesn't "empower" them to do whatever they want at the local level for local goals while the whole system deteriorates.
This is a social problem requiring systems thinking. Most people who read articles like this create more problems than they solve because they try to fix the problem analytically rather than systematically.
How NOT to Fix Code Discovery
We can't fully address how to fix code discovery here—it's too involved and context-dependent. But we can tell you how not to do it:
- Don't create gates
- Don't create approval processes
- Don't create databases and tools that require manual entry
These approaches seem to make sense, but they're nonsense. They create more work. It's like putting nice clothes on a body that's rotting internally.
How SDLC That Works Addresses This
At organizations with functioning SDLC systems—including the SDLC we provide—code discovery and related issues (code ownership, branching, CI/CD) are handled exceptionally well. We know exactly where each piece of source code is, who wrote what, how much, and when. When small changes require modifications to hundreds of applications, a single developer can execute them—something that requires waking hundreds or even thousands of developers in most organizations, with a program manager tracking progress. For orphaned repos, don't even get started.
Code discovery is rarely discussed in SDLC conversations, but it should be the first topic. In any other industry, not knowing where your core assets are would be considered catastrophic negligence.
Mini Case Studies: The Real-World Impact
Case Study 1: The Ghost Developers
When fixing SDLC for one company, the first thing we worked on was code discovery and code ownership. Once we could provide a list of how much code was written by each developer—something only possible after fixing code discovery—we discovered something shocking.
Out of 4,000 developers, 800 had not written more than 100 lines of code in the last six months.
When we investigated, managers didn't contest the names. These 800 developers were described as "very busy" and "critical for organization project delivery." So what were these 800 developers doing if not writing code, writing tests, or fixing incidents?
We'll discuss that case study in detail another time, but we can sense similar patterns happening in many organizations. After fixing other parts of the SDLC, the role of these 800 people was completely eliminated—not because they were bad people, but because they weren't great developers, and no good developer would do the work (which was only critical for that broken SDLC system) that they were doing.
Case Study 2: The Million-Line Explosion
In another case study, we tracked the growth in lines of code. The codebase jumped by millions of lines over a single month. What happened?
Developers were copying entire open-source source code into repositories as-is. Not only that—the code was copied multiple times across different teams because the system for creating shared libraries was broken.
This is very rampant in many organizations. But even if it's not happening at your company, there's no way to know unless you keep track of lines of code at the enterprise as a whole and ask the right questions.
Case Study 3: The 80-Fold Duplication
In another case study, AddressValidator code was copied 80 times across many applications. When there was an incident that required fixing address validation, the localization team responsible for address validation had to work with 80 different teams by throwing 3 program managers at the problem.
But here's the real cost: hundreds of security patches were never addressed because the cost was too high. When you have to coordinate with 80 teams to fix a security vulnerability, many organizations simply don't do it.
Case Study 4: The Five-Minute Task That Never Ended
In one case study, we brought together the DevOps Product Manager, Chief Architect, and a few others and gave them simple tasks:
- Find the source code for XYZ service
- Find the source code for secure file upload functionality
- Similar simple tasks that should take five minutes
The resulting craziness was huge. Not one person could finish a five-minute task even after hours of searching.
They understood how broken the systems were. Did they do something to fix it? Most case studies tell you how they fixed the systems, but not in our case. They continued to work on technological solutions because fixing social systems requires true leadership skills. To fix code ownership, they needed to convince leadership at the top and developers at the bottom—but their goals and KPIs weren't aligned with any of that.
If you have a broken code discovery problem, first don't be ashamed of it. It's a very general social problem, mostly induced via polyrepo and microservices architecture.
The Hive Analogy
We can cite more and more case studies, but think of it this way: if bees work on their hive, engineers work on their code hive. Managers, governors, and even engineers need to know where the source code for all different dependencies lives. Without that knowledge, you don't have a functioning hive—you have chaos.
The Bottom Line
If you can't answer basic questions about your code—how much exists, where it lives, who owns it—you don't have code discovery. And if you don't have code discovery, you don't have a functioning SDLC. You have organized chaos masquerading as software development.
The question isn't whether you can afford to fix it. The question is whether you can afford not to.
How can Organization go about fixing Code Discovery
Since code discovery is fundamentally a social challenge rather than a technological one, no universal tooling solution exists. Each organization's SDLC has evolved uniquely, requiring solutions tailored to their specific code ownership models, CI/CD systems, release checklists, and deployment pipelines. However, code discovery is entirely solvable, and the insights gained from organization-wide code discovery can deliver value worth millions. When transforming an SDLC, rather than beginning with the typical focus areas—quality, product management, or CI/CD pipelines—the transformation should start with code discovery. We have fixed Code Discovery Problem for few organizations and we will be happy to help you to educate your Systems Change agents on how to go about doing it. Reach out to us.
