Tao Te Dev 5: effectiveness in chaos

This is an entry in the Tao Te Dev series. This series is a very un-scholarly interpretation of the Tao Te Ching which applies the wisdom found to the world of software development. Learn what you can, but don’t take anything written here as actual life advice.

The Tao doesn’t differentiate;
from it arise both good and evil.
The wise engineer doesn’t differentiate;
they welcome all

The Tao is empty without being exhausted;
the more it works, the more is given.

Communication pushes out.
Better to hold fast to the center.

We’ve departed some from architecture and software inner-workings and moved on to living in the chaos that is a software project.

Good and Evil

Good and Evil are created concepts. They themselves are named things, manifestations of the tao’s work. We’ve discussed some of this in Chapter 2. In order to be effective as engineers, we also need to lose this distinction.

Some code we work with will be good, some of it will be evil. Some tools we work with will be good, some tools will be bad. Some people we work with will be good, some of them will be bad. Allowing any of these situations to be even considered in day to day life blocks things getting done – the tao does not differentiate and therefore is able to simply act. We also need to not differentiate.

We lose effectiveness when we look at these distinctions and give value to them. We need to empty ourselves of these distinctions, and therefore allow things to be produced.

Empty without being exhausted. Have you ever found yourself exhausted while working on a large project? Did that exhaustion come from performing the work itself, or from the conversations and battles between “Good” and “Evil” surrounding the actual work? Be empty – lose the concept of Good and Evil – and the work will get done without exhaustion.

Too much communication

On any project, communication is important. There’s a certain amount of information you need in order to be effective. Too much, however, is bad.

Another interpretation of this line is “The more you speak, the less you understand.” Perhaps that’s why Lao Tzu uses so few words in his passages

Communication pushes out — those who communicate a lot are in the clouds, far away from understanding. Communication, the active communication of polling, statusing, asking and answering questions until everyone is “on the same page” — really just pushes us out, away from the center.

Why is it better to hold to the center? Because that’s where the understanding is. One often must actively work to stay there, because the normal hum of chaotic projects will pull you away.

The center is the center of everything on the project – the silence, the void that spawns the ideas, code, deep understanding of everything involved, and through actions, eventually the product itself. Lao Tzu is telling us it’s better to stay closer to that silent center than to ride the outer waves of the project’s communication and chaos.

The center, the silence, is understanding. Understanding is null. The further away from the center we get, the less we really understand.

Lao Tzu’s reminding us that even in the middle of chaos, we can still return to understanding by simply letting go. But even more interestingly – he’s telling us it’s better to under-communicate – which is the complete opposite the typical corporate mantra.

There are different ways to under-communicate, and there is a lot of situation-specific nuance here; but overall, this is exactly the counter-intuitive advice it seems like.

Communication breeds the very differentiations that block work; communication defines things as good or evil; communication spreads misunderstanding – the more you speak, they less you understand. Therefore under-communicating helps you and the listener stay closer to the center and retain understanding.

The people on good projects don’t check email often. The people on great projects are able to make decisions without much communication – remaining close to the center and able to make those decisions while retaining understanding.

Chaotic projects have one thing in common — their decisions are being made far from the center, and far from understanding.

If you’re on a chaotic project, keep in mind—

Communication and understanding are linked to one another. Anyone who feels they need over-communicate in order to get things done very likely lacks understanding. This goes for anyone involved — out of touch, demanding customers; out of touch management; and even the “just trying to clarify” engineer.

Agile development practices teach us to bring the customer into the planning and development process, specifically because they expect this interaction will increase the customer’s understanding and therefore improve the guidance and demands the customer makes. This is a good end goal, but it makes a terrible assumption— teaching understanding (of anything) is nearly impossible.

You can ensure access to the information needed to understand the situation, but that’s all — the next step is up to the stakeholder themselves. Understanding anything on any level is an internal process the individual must undertake on their own.

You can lead a horse to water, but once you’re there, the only other thing you can do is get frustrated. Trying to get a stakeholder to really understand something is often like trying to teach a pig to sing. The way to address this issue isn’t to attempt to increase the stakeholder’s understanding.

There is a better way.

The link between understanding and communication is a two way link. If you enable the stakeholder to communicate less, soon you’ll find they understand more. The thing to focus on is answering the questions before they are asked, or better yet, prevent the need for questions to be asked. Make the realities of the project self-evident, so clarification is never needed. Make polling and statusing a thing of the past.

Taking steps to reduce the need for communication will pull everyone back towards the center, and increase understanding across the project. Having everyone making their decisions near the center — with good understanding — is the difference between a good project and a bad one.