Forest & Desert
This guest post is written by
, following discussions we had preparing for our recent Øredev pair keynote (link to come).
“This architecture you’ve described sounds like a lush forest, but we are living in the desert. I don’t see how this will work here.”
I am often confronted with skepticism, but seldom is it so constructively put.
Desert
In a software desert, we travel by force of will under an oppressive heat, with saddlebags stuffed to the brim. There is no room for error in the desert, no opportunity for good news, no time to revisit a place we have already been. It is very important that we know how long the journey will take, even when we aren’t sure that where we end up will be any better than where we started.
Forest
Some of us have experienced a software forest, once upon a time. There was a team that just worked. A company where things were built in small, safe steps and we architected as we went along. A time a whole group of people shared a clear goal and we were all going after it as best we knew how. A place where on call was no big deal because we didn’t have bugs to be paged about.
When we talk about “building software”, we aren’t all talking about the same job. Building in the desert? Building in the forest?
Which?
There is a lot of advice targeted at the desert. Write detailed design documents. Have senior engineers do more project management. Mandate multiple levels of review. Build microservices that align with autonomous team boundaries. Spend more time estimating. Optimize for your performance review. Rewrite what isn’t working. Create a sense of urgency.
That advice doesn’t make sense in the forest.
There is also advice targeted at the forest. Have developers write tests. Practice collective code ownership. Build incrementally. Refactor. Host guilds. Pair. Release continuously. Work on smaller slices. Run experiments. Stop setting deadlines. Host weekly demos.
Those techniques don’t have the intended effect in a desert.
Here To There
There is a path from the desert to the forest, a series of small, safe steps a community can take to terraform the landscape. No developer can do it alone, and no amount of technology will get us there, but it is possible.
Before we start that journey, it is worth understanding why a company has built a desert. Sometimes it is just an accident. Other times the fruits of the forest aren’t valuable to the executive team, whereas the fruits of the desert are.
If executives don’t care about user trust, consistent design isn’t going to be useful. If bugs don’t have any impact on the bottom line, there is no reason to avoid them. When the challenge is legibility and control of processes rather than how to deliver useful software to the users, delivering useful software more efficiently doesn’t earn us anything. Trying to write clean code in a company getting anything at all done with a minimum of resources just makes developers sound self-righteous. Worse, it convinces programmers that forest techniques don’t work, can’t work, and are never worth doing.
Staff+
Executive teams shouldn’t have to understand how software developers do their jobs to get the outcomes they want. That is where Staff+ Engineers come in. Our job is to partner with business leaders to understand the goals, and then cultivate the landscape that can deliver on them.
 |
|
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 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.