I think the most important distinction is trust vs fear. In the forest, people have high trust (in each other, themselves, the software, the future potential, etc). To transform a desert into a forest requires people to let go of norms and values that build fear and replace them with ones that build trust. But that letting go also requires trust which is in short supply.
This "Forest vs Desert" is an insightful analogy about a project's business environment.
But it does immediately make me think that the real difference may be …
>>> "Are we in a war zone?" <<<
… of our own making
…
And not "Of course; we're battling the competition!" but rather, "Within our company, we're a bunch of feudal warlords, battling for control in a zero-sum game." 😢
Environments are all different, and I think that's the biggest challenges: even a lush forest can feel like a desert if you are missing something. And there is many deserts: sand, ice, the ocean... What is missing in one of them can be plenty in another.
Moreover, what looks as a desert for someone, can be full of hidden richness for someone else. Adapting to our environment, being able to learn, is a consistent key to survival.
And let not forget desertification and terraforming: environments changes and consequently, are rarely uniform.
Overall, the ability to map our environment consistently and precisely is still a hard thing to do. The old maturity models feel inadequate and right now, the only model I know about that try to do such mapping are Wardley's maps. Is there anything else?
We're not talking about subtle differences. There are 2 major attractors in software development:
* Reduce resources to a minimum & still get anything done.
* Expand resources but remain profitable & sustainable.
Which of these you live in profoundly affects whether a particular practice is helpful or harmful.
Empirically, most of software is written under the first of these constraints (the desert). The occasional delightful exception proves the second (the forest) is possible. It's ephemerality suggests it's also fragile.
I'm not sure about this polarity. I worked in places where time was missing but not money, or where I have little experienced seniors but lot of talented interns, where we have few hands but high talented people, etc. Right now, I'm working with a very popular IP which is also very different from working with a unknown one. Each of those environments have required me to adapt to what's missing, and the resources we have at hand. None of them feels like a total desert nor like a infinite resourceful lush forest. It defines what you can do, where you should focus, what's important and what's not. I really doubt that I can clean cut it to a either do or not, there is way too many dimensions for that.
For the paragraph starting with "If executives don’t care ..."
Do you have concrete examples of where executives don't care, for example, about bugs in software. I am having a hard time thinking of anyone admitting something like that out loud. So it is more "through their actions" they don't care you are referring to (in which case it is an exercise in education with the execs) or they literally don't value bug-free software?
https://sre.google/sre-book/embracing-risk/#id-na2u1S2SKi1 This institutionalizes the idea of a defect budget. Yes, at scale, some defects are inevitable. But some are very much evitable (if that's a word). In the forest, we catch those before production.
The desert or the forest—perhaps the biggest challenge lies in the courage to admit where we truly stand before we attempt to build anything.
I just remembered Kent's first book referencing to "Forrest People, Mountain People." Insightful.
I only have a few tricks so I keep reusing them
I think the most important distinction is trust vs fear. In the forest, people have high trust (in each other, themselves, the software, the future potential, etc). To transform a desert into a forest requires people to let go of norms and values that build fear and replace them with ones that build trust. But that letting go also requires trust which is in short supply.
And that's why you start with community. You can build the beginnings of the necessary trust in a small, defined community. Work outwards from there.
This "Forest vs Desert" is an insightful analogy about a project's business environment.
But it does immediately make me think that the real difference may be …
>>> "Are we in a war zone?" <<<
… of our own making
…
And not "Of course; we're battling the competition!" but rather, "Within our company, we're a bunch of feudal warlords, battling for control in a zero-sum game." 😢
Environments are all different, and I think that's the biggest challenges: even a lush forest can feel like a desert if you are missing something. And there is many deserts: sand, ice, the ocean... What is missing in one of them can be plenty in another.
Moreover, what looks as a desert for someone, can be full of hidden richness for someone else. Adapting to our environment, being able to learn, is a consistent key to survival.
And let not forget desertification and terraforming: environments changes and consequently, are rarely uniform.
Overall, the ability to map our environment consistently and precisely is still a hard thing to do. The old maturity models feel inadequate and right now, the only model I know about that try to do such mapping are Wardley's maps. Is there anything else?
We're not talking about subtle differences. There are 2 major attractors in software development:
* Reduce resources to a minimum & still get anything done.
* Expand resources but remain profitable & sustainable.
Which of these you live in profoundly affects whether a particular practice is helpful or harmful.
Empirically, most of software is written under the first of these constraints (the desert). The occasional delightful exception proves the second (the forest) is possible. It's ephemerality suggests it's also fragile.
At best I've gotten to work in a scrubland.
I'm not sure about this polarity. I worked in places where time was missing but not money, or where I have little experienced seniors but lot of talented interns, where we have few hands but high talented people, etc. Right now, I'm working with a very popular IP which is also very different from working with a unknown one. Each of those environments have required me to adapt to what's missing, and the resources we have at hand. None of them feels like a total desert nor like a infinite resourceful lush forest. It defines what you can do, where you should focus, what's important and what's not. I really doubt that I can clean cut it to a either do or not, there is way too many dimensions for that.
For the paragraph starting with "If executives don’t care ..."
Do you have concrete examples of where executives don't care, for example, about bugs in software. I am having a hard time thinking of anyone admitting something like that out loud. So it is more "through their actions" they don't care you are referring to (in which case it is an exercise in education with the execs) or they literally don't value bug-free software?
https://sre.google/sre-book/embracing-risk/#id-na2u1S2SKi1 This institutionalizes the idea of a defect budget. Yes, at scale, some defects are inevitable. But some are very much evitable (if that's a word). In the forest, we catch those before production.