In any software project, code naturally organizes itself into modules—collections of files and directories that form the building blocks of a system. But while software engineering loves the idea of modularity, the reality of who controls these modules tells a deeper story.
Some modules are massive, spanning a significant portion of the codebase—what we call significant modules. Others are smaller but still critical. Yet, the most interesting (and sometimes dangerous) aspect of modules isn’t their size, but their ownership.
Who Owns the Code?
In a well-balanced team, modules have multiple contributors and shared ownership. But in real-world development, some modules end up under the strong control of a single developer or team.
- A module owner is the person or team that has written over 50% of the module’s code.
- A module contributor is any developer who has contributed code to the module but doesn’t own it.
So, what happens when an important module—one that represents a significant portion of the project—falls entirely under the control of a single developer?
The Rise of Dark Modules
A dark module is a significant module where a single developer owns most or all of the code. This isn’t just about a developer contributing a lot—it’s about exclusive control. No one else regularly touches this module, meaning knowledge is concentrated in one person’s head.
Advantages:
- Speed – The owner has deep familiarity with the code, allowing for rapid development and iteration.
- Consistency – A single vision drives architectural and design decisions, leading to a more cohesive implementation.
Challenges:
- Fragility – Over-reliance on a single developer increases the risk of burnout, which can slow down the entire project.
- Risk – If the owner leaves, the module becomes difficult to maintain or extend, effectively turning into a black box.
- Bottleneck – With no other contributors, development stalls if the owner is unavailable.
The Lone Developer Problem
Now, imagine a developer who doesn’t just own one dark module—but several. This is what we call a lone developer: someone who regularly owns multiple dark modules in a project.
These developers become single points of failure. They’re the only ones who understand entire sections of the system, which makes them both indispensable and dangerous. Companies may love their efficiency, but as soon as they leave (or worse, burn out), the project is left scrambling to recover. A dark module is a problem in how the team works, but if a single developer is always working alone on a specific module, this might be a symptom of a problem with the developer’s behavior and might need tackling.
How do we detect lone coders using Codenteam?
Directly on the homepage of a run, you can see the Lone Developers graph as follows:
For each profile, you can see an inside bar, this bar can be green or red. Usually, a single profile owning a couple of modules out of a dozen contributed-to modules doesn’t necessarily mean an issue. However, if the inside bar is red, this means the developer is contributing to specific significant modules they own, and most probably is a regular behavior that needs addressing.
How Do We Fix This?
Lone developers and dark modules aren’t inherently bad, but they pose a risk. Here’s how teams can balance efficiency with sustainability:
- Encourage Shared Ownership – If a module has a sole owner, actively push for more contributors. Code reviews should be done by someone outside the module.
- Cross-Train Developers – Ensure that at least one or two other people can navigate and contribute to significant modules.
- Document More, Rely Less on People – A lone developer’s knowledge should live in documentation, not just in their head.
- Automate Testing – When a module has only one person working on it, tests act as a safeguard against unintentional breakage when others step in. And then can allow diluting the developer code without the fear of breaking the legacy code.
- Recognize the Lone Developer – If someone owns too many dark modules, redistribute the load before it’s too late.
Lone developers are often brilliant, efficient, and fast. But software isn’t just about writing code—it’s about maintaining and evolving it over time. The more we embrace modularity without addressing ownership, the more we risk creating knowledge silos that can break projects in ways we never expect.
