The Ninki Nanka Problem: Why Uncertainty Destroys Well-Intentioned Software and AI Projects

In software engineering, uncertainty enters through many doors, but not all are equally dangerous.

The most destructive uncertainty concerns the problem itself. There is no greater waste than building an elegant solution to the wrong problem. As John Gall observed, “an intervention must operate at the correct logical level to be effective”. Today, we live in a world awash with solutions. The harder task is determining which problems genuinely exist and which merely sound compelling.

Closely following this is uncertainty about users. Many developers are trained in environments where problems are neat, bounded, and fully specified. Real users are none of these things. Their needs are contextual, often tacit, and shaped by constraints invisible to designers. Software built around imaginary users, phantoms assembled from assumptions, almost always fails quietly.

Then comes design. Design is not decoration. It is the act of thinking problems through to exhaustion before committing them to code. A good design functions as a build manual, exposing contradictions, edge cases, and dependencies while they are still cheap to fix. Skipping this step does not accelerate delivery; it merely delays decision-making until the most expensive moment.

Technology choices introduce their own uncertainties, particularly in an era where new AI tools appear weekly. Novelty is intoxicating, but every choice constrains future options. Selecting technology is not about fashion, it is about narrowing uncertainty responsibly.

Finally, there is delivery uncertainty. Do you truly have the people, time, and attention required? Are teams focused, or spread thin across competing priorities? Under-resourced projects do not fail loudly. They erode slowly.

When AI Enters the Picture

AI intensifies uncertainty rather than eliminating it.

Outputs may appear fluent and confident while being subtly wrong. Failures can be difficult to explain, harder still to predict. Operational costs, especially for large language models, can render a viable prototype economically unsustainable at scale. Dependency on external vendors introduces strategic fragility that is often discovered too late.

AI systems, perhaps more than any other technology, reward scepticism.

What the Swamps Can Still Teach Us

The people who feared the Ninki Nanka were not naïve. They were responding rationally to uncertainty with the tools they had: story, caution, restraint.

We would do well to recover some of that sensibility

Folklore as a Primitive Risk Management System

What strikes me about the Ninki Nanka stories is not their strangeness, but their efficiency.

The Mandinka were not conducting environmental impact assessments. They were not running probabilistic hazard models of swamp ecology. Yet they arrived at a remarkably effective behavioural outcome: people avoided dangerous places without needing to understand precisely why they were dangerous.

This is the first deep parallel.

Another overlooked feature of the Ninki Nanka myth is how overdetermined it is.

The creature is not just big. It is fatal to look at. It causes sickness merely by being seen. It inhabits places that are simultaneously fertile and dangerous. Even indirect contact, seeing its body but not its eyes, is enough to bring harm.

This is not narrative excess. It is redundancy.

Folklore designers, whether consciously or not, knew something modern system designers routinely forget: warnings must be stronger than curiosity. If the story had been subtle, it would have failed. If only some encounters were dangerous, people would test the boundary. If the punishment were mild, risk-taking would creep in.

So the story exaggerates. It stacks consequences. It leaves no room for casual experimentation.

Now compare this to how uncertainty is treated in software projects.

Early signals, vague requirements, unclear ownership, immature technology, are routinely dismissed as “normal” or “things we’ll sort out later.” Teams continue forward precisely because the consequences have not yet been made vivid enough to override momentum. There is no Ninki Nanka in the room, no shared symbol that says this path is dangerous even if we can’t yet articulate why.

By the time the danger becomes undeniable, the project is already deep in the swamp.

Why Folklore Prefers Prevention Over Cure

One of the most revealing aspects of the Ninki Nanka myth is that there is no heroic victory over the creature. No slaying. No conquest. The winning strategy is avoidance.

This is profoundly unmodern.

Modern engineering culture celebrates intervention. We fix things. We debug. We refactor. We recover. The implicit belief is that intelligence and effort can overcome any obstacle given enough time.

Folklore does not share this belief.

Folklore assumes that some systems are too complex, too opaque, or too dangerous to engage directly. The rational response is not mastery but restraint. Do not go there. Do not look. Do not try.

In software and AI, this translates into an uncomfortable lesson: some projects should not start. Some architectures should not be attempted. Some uses of AI should be declined, not because they are impossible, but because the uncertainty envelope is too large relative to our capacity to manage it.

Flamanville 3 is not a story about failure of execution. It is a story about entering a swamp believing one could always find dry ground later.

Stories as Memory Across Generations

There is one final, subtler parallel.

Folklore persists where documentation fails.

The Ninki Nanka story survived without design documents, without formal education systems, without version control. It was robust to personnel turnover. It did not depend on a single expert. It embedded itself into culture.

Software projects, by contrast, routinely lose institutional memory within a few years. Teams change. Context evaporates. Decisions made under uncertainty are forgotten, and the same mistakes are repeated by new hands convinced they are seeing the problem afresh.

This is not a tooling failure. It is a storytelling failure.

When uncertainty is not named, not narrated, not ritualised, it disappears from collective memory. Each new team rediscovers the swamp on its own terms.

Folklore solved this by making uncertainty unforgettable.

What This Implies for Modern Systems Work

If we take the folklore parallel seriously, and I think we must, then the lesson is not merely “be careful with uncertainty.”

It is this: uncertainty must be made socially real.

It must be visible, discussable, memorable. It must influence behaviour before evidence is complete. It must occasionally feel exaggerated, even unfair, because that is how it competes with ambition and momentum.

In other words, every serious software or AI organisation needs its own equivalent of the Ninki Nanka: not a superstition, but a shared story about where danger lies, why caution is rational, and when walking away is wisdom rather than weakness.

The people of the lower Gambia did not fear the swamp because they misunderstood it.