False Dichotomies Are the Enemy of Progress

There is a particular kind of professional conference talk that I stopped finding interesting a long time ago: the one that takes two things and declares that you must choose between them.

Waterfall vs. Agile. Testing vs. Coding. Operations vs. Development. Documents vs. Working Software. Process vs. People.

These are the battle flags of tribes. And tribal battles do not produce good software or well-run organizations. They produce camps, and camps produce stagnation.

The Structure of a False Dichotomy

A false dichotomy works by taking two things that exist on a continuum — or that are both valuable in different contexts — and presenting them as an either/or choice with a correct answer.

The people offering the choice usually believe it sincerely. The Agile advocate who says "waterfall is dead" is not trying to deceive; they have genuinely observed the damage that rigid upfront planning causes in complex, uncertain environments, and they have found adaptive approaches to be more effective. Their experience is real.

What they have done is abstract from their experience to a universal claim: the way I have found valuable is the way, and the other way is wrong. This is the move that creates the false dichotomy.

The diagnostic question for any presented dichotomy: does the correct answer depend on context, or is one answer correct regardless of context? If context matters — and it almost always does — the dichotomy is probably false.

The Battlefields I Have Watched

Waterfall vs. Agile. In a well-understood problem with stable requirements and low uncertainty, upfront planning is valuable. In a novel problem with uncertain requirements and high variability, iterative adaptation is valuable. Most real projects have elements of both. The question is not "which approach is right?" but "which aspects of each approach fit this part of the problem?"

Testing vs. Coding. The person who says "we don't have time to test because we need to write code" has set up a false opposition. Tests are the mechanism by which you know your code does what you think it does. The choice to skip testing is not a choice to do more coding; it is a choice to do coding whose correctness you cannot verify.

Operations vs. Development. The DevOps movement was a direct response to this false dichotomy. Organizations that treated Development and Operations as separate, competing functions — with an adversarial handoff between them — produced systems that were hard to deploy, slow to change, and difficult to operate. The synthesis was not to pick a side; it was to recognize that the boundary was artificial and that the combined team produced better outcomes than either side alone.

Documentation vs. Working Software. The Agile Manifesto's formulation — "Working software over comprehensive documentation" — is often interpreted as "documentation is bad." That is not what it says. It says that when you have to choose, prefer working software. But in the Intent Era, AI enables both simultaneously. The dichotomy was a constraint of human execution capacity, not a principle.

Why Tribes Form Anyway

False dichotomies persist because humans are wired for tribal identity. "We are Agile" is a cleaner identity than "we are adaptive in proportion to the uncertainty of our context and planful in proportion to what we know." The first is a flag you can wave. The second requires ongoing judgment.

Tribal identity in practice communities also has a valid function: it coordinates behavior among people who have not worked together long enough to share tacit understanding. "We are an Agile team" signals a set of norms that a new member can learn quickly. The price of that efficiency is that the tribe tends to overextend its norms to contexts where they do not fit.

The practitioner who has moved past the tribal stage uses each approach as a tool rather than as an identity. This requires a certain amount of comfort with ambiguity — the willingness to say "in this context, the Agile approach is right, and in that context, the structured planning approach is right" without feeling that the inconsistency is a failure.

The AI-Era False Dichotomies

The technology field is currently generating a new set of false dichotomies around AI, and they follow the same pattern:

Human expertise vs. AI capability. In most situations, the strongest result comes from human judgment + AI execution, not from either alone. The question is where the boundary should be and how it should be managed — which requires ongoing judgment rather than a policy.

Assistance vs. Autonomy. The 8-stage trust evolution I use in my talks is a direct rejection of this dichotomy. Autonomy is not a binary setting. It is a function of the infrastructure you have built, the governance you have in place, and the specific task at hand. Stage 3 autonomy is not Stage 7 autonomy, and both are appropriate in different contexts.

Speed vs. Safety. Governance is framed as the opponent of speed in this dichotomy. In reality, governance is the enabler of speed at scale. You cannot run 10 concurrent autonomous agents without governance infrastructure. The choice is not fast or safe; it is: do you want to go fast at small scale, or do you want to go fast at the scale AI makes possible?

Name the false dichotomies in your field. The moment you have named them, you can start to move past them.

Part of the Thought Leadership series — Thread 2: Technology Practice & Evolutionary Change. Related: [[T12-language-limits-thought]], [[T14-vocabulary-as-force-multiplier]], [[T33-post-ai-agile-manifesto]]