Every engineering team has a Dolly Parton. It's the one person, library, or internal service that's been around forever. It's universally loved, incredibly prolific, and works so reliably that you've forgotten to wonder how. You just assume it will be there tomorrow.
Then one day, it isn't. As Hacker News reported, the world lost a true institution. And while the cultural impact is immeasurable, it forces a question we should be asking about our own systems: what happens when your most reliable, taken-for-granted dependency disappears overnight?
This isn't a hypothetical. We once worked with a client whose 'Dolly' was a guy named Dave. Dave wrote their core transaction processing engine in 2008. It was a beautiful, efficient piece of C++ code that handled millions of dollars a day without a hiccup. Dave was a genius. But the only documentation was in his head, and the only person who could debug it was him. When he retired, a critical piece of their business infrastructure instantly became a black box. That's the Dolly Parton Problem.
What Makes a "Dolly Parton" Dependency?
These critical dependencies aren't just any old library or API. They have a specific signature. They are often victims of their own success, becoming so ingrained in your operations that they become invisible.
Longevity and Stability
It's been in production since before your company used Git. It just works. Maybe it's a Perl script that generates end-of-day reports or an old Struts application that serves a critical but forgotten admin panel. Because it never breaks, it never gets attention. It's not on any roadmap for upgrades or rewrites. It's infrastructure, like the plumbing in the walls.
Opaque Internals
Everyone on the team knows its API. You send it a customer ID, you get back a transaction history. Perfect. But no one currently on payroll knows how it works inside. The original authors are long gone. The code has zero comments, the commit history is meaningless, and there are no tests. You can't change it because you're terrified of breaking it.
Implicit Trust
The system is so reliable that no one has built proper monitoring or fail-safes around it. Alerts? Logging? Psh. It's never failed, so why plan for it? The operational readiness checklist for this service is just "hope". This is the most dangerous part. The trust isn't a calculated risk, it's an assumption. And assumptions are the mother of all outages.
The Real Cost of a Sudden Disappearance
When your Dolly Parton dependency vanishes, the impact is immediate and often catastrophic. It's not just a P1 ticket. It's a business crisis that your engineering team is completely unprepared to handle.
Scenario 1: The Key Person Leaves
This is the classic "Dave the C++ guy" problem. The day he walks out the door, you lose your entire support model for a business-critical system. You can't fix bugs. You can't add features required by a new partner. When a high-value customer reports a strange edge case, your answer is a shrug. The business is now held hostage by a piece of code nobody understands.
Scenario 2: The API Sunsets
This is what happened with platforms like Parse. Teams built entire applications, even entire businesses, on its backend-as-a-service platform. When Facebook announced its shutdown, those teams faced an existential threat. They had to drop their entire roadmap for a year to re-architect everything from scratch. Your internal 'Dolly' API might not be a public company, but the effect is the same if the team supporting it gets re-org'd and the service is put into maintenance-only mode with a one-year EOL notice.
Scenario 3: The Library Is Compromised
Sometimes the dependency doesn't just disappear, it becomes toxic. A critical vulnerability is discovered in a foundational library that your 'Dolly' service uses, like Log4j. Now you're in a mad scramble. You have to patch it, but to patch it you have to build it. To build it, you have to find the old build environment. That means dusting off a copy of Eclipse 3.5 and finding a JDK 6 installer. Your security compliance is blown, and your team is on an archaeological dig instead of shipping features.
How to De-risk Your Dolly Partons
This isn't about blaming Dave or avoiding stable libraries. It's about turning implicit assumptions into explicit architectural plans. It's about resilience. You can't eliminate dependencies, but you can manage the risk.
Step 1: Identify Them
First, you have to find them. This requires an honest conversation with your senior engineers. It's an institutional knowledge audit. Ask these questions:
- If one person won the lottery and quit tomorrow, what part of our system would be most at risk?
- What piece of code are we most afraid to deploy?
- Which service has the bus factor of one?
Make a list. Be brutally honest. That list is your high-priority technical debt.
Step 2: Document the API and the Internals
For each item on the list, the first job is documentation. But not just API docs. You need architectural decision records (ADRs), operational runbooks, and deep-dives into the code's logic. Force a rotation. Make a junior engineer pair with a senior to add a new log line to the service. The goal is to spread the knowledge. At AgileStack, we treat internal documentation for our clients' core systems as a first-class product, because it is.
Step 3: Introduce Redundancy with the Strangler Fig Pattern
For the highest-risk systems, documentation isn't enough. You need a replacement strategy. The Strangler Fig Pattern is your best friend here. Don't plan a big-bang rewrite. Instead, build a new, modern service that replicates a tiny piece of the old system's functionality. Then put a proxy in front of the old service that routes a small percentage of calls to the new one.
Here’s some pseudocode for what that proxy might look like:
// Pseudocode for a simple Strangler Fig proxy
// using an Express.js-like framework.
app.post('/api/legacy/process-payment', async (req, res) => {
const accountId = req.body.accountId;
// Use a feature flag or % rollout to decide the path
if (featureFlags.isEnabled('new-payment-service', accountId)) {
try {
// Attempt to use the new, modern service
const result = await newPaymentService.process(req.body);
// IMPORTANT: Compare results if possible, log discrepancies
// compare(result, oldPaymentService.process(req.body));
return res.json(result);
} catch (error) {
logger.error('New payment service failed. Falling back.', { error });
// Fallback to the old reliable service on failure
const result = await oldLegacyService.process(req.body);
return res.json(result);
}
} else {
// The default path is the old, trusted service
const result = await oldLegacyService.process(req.body);
return res.json(result);
}
});
Over time, you implement more and more functionality in the new service, gradually "strangling" the old one until it has no responsibilities left. Then you can safely decommission it.
What This Means for Your Team
It’s easy to look at a stable, reliable piece of your infrastructure as a solved problem. The reality is that stability can mask fragility.
Here are the key takeaways:
- Every team has undocumented critical dependencies. Your job is to find them before they fail.
- Key person risk is a form of architectural debt. Paying it down requires proactive effort in documentation and cross-training.
- The Strangler Fig Pattern is the safest way to replace a critical component. It allows you to de-risk the process incrementally.
- Assume any dependency can and will disappear. Your architecture should be resilient enough to handle that reality.
The point isn't to live in fear of your dependencies. It's to know which ones would break your business if they were gone tomorrow. Run that audit. Ask the hard questions. Your next roadmap, and maybe your next job, could depend on it.
Building something in this space? AgileStack helps teams ship enterprise-grade software without the consulting-firm overhead. Book a 30-minute call and tell us what you're working on.