Forest or Desert... or both?

The Forest and Desert metaphor is a compelling way to highlight the communication gap between software teams in different working conditions, but it risks slipping into absolutism and evangelism.

I don’t like it.

It sets up a dichotomy where the Forest is seen as the enlightened, flourishing state of software development (agile, tested, customer-focused) while the Desert is a place of dysfunction, scarcity, and struggle. This framing is seductive, but ultimately incomplete and potentially harmful.

Deserts are not failed forests. They are valid ecosystems with their own logic, beauty, and resilience.

In many contexts, software teams operate in environments where constraints are real (scarce time, low budgets, minimal staffing, bureaucratic limits) and within those conditions, they often do remarkable things. There is wisdom in minimalism, just-in-time problem solving, and hard-won local optimisations.

These aren’t dysfunctions to be corrected by importing Forest practices wholesale; they are adaptive responses to real-world limits.

Moreover, the Forest is not the utopia it’s made out to be. Forests are teeming with life, yes, but also with predators, disease, and decay. Even well-run agile teams can harbour technical debt, groupthink, poorly understood legacy systems, or simply a false sense of superiority.

It’s more useful to think in terms of ecology, not conversion. Forests and deserts are both viable, intricate systems. They require different tools, instincts, and rhythms. The challenge is not to bring water to the desert until it blooms like a forest, but to understand the genius of how each environment supports life, and to work with that, not against it.

I understand it’s a metaphor and, like all metaphors, is an intentionally flawed model meant to offer insight, but I don’t find it helpful.

Originally posted on LinkedIn.