Tao Te Dev 2: let go and persist

When everyone agrees some things are beautiful,
other things become ugly.

When everyone agrees some practices as good,
other practices become loathsome.

Yet
Procedural and OO create each other.
Easy tasks create the difficult.
Long and short shape each other.

High and low;
Before and after;
require lookups.

The wise engineer
acts without doing
and advocates without advocating.

things arise and the engineer lets them come;
things deprecate and the engineer lets them go.

The engineer bears,
but does not possess,
creates but does not retain.

to do the work and let it go;
for letting it go
is what lets it persist

Lao Tzu’s given us a lot to discuss here.

At one time, COBOL was the coolest programming language ever. Everyone wanted to write their next enterprise application in COBOL. What happened? Everyone decided that other languages were more beautiful, and therefore something had to become ugly.

The same story can be told for project management and estimation methods, frameworks, development platforms, and pretty much everything else.

There are two important lessons here:

1. The universally recommended concepts and tools in the development world are culturally constructed. Being able to see through that facade and see what’s actually useful in a given circumstance is a rare skill that must be actively practiced to develop. I contend that this skill is the essence of the tao — being able to strip away the names and labels in order to determine how closely something follows The Way.
2. To believe that any tools or concepts in the development world are anywhere near permanent truths is straight up arrogance; things will change, the beautiful will become ugly, and the ugly will be reclaimed. So even if the good and bad things are culturally defined, things will come and go.

Considering the above, the wise engineer accepts change both in embracing the new (when it’s ready) and letting go of the old (when it’s time for it to go). The Tao can be fought, but it is undeniable.

Go ahead and try to fight change. You’ll lose, and the thing you’re trying to preseve will be reclaimed. It’s only a matter of time. Enabling change is the path to persistence.

Transformation of the named things in our world is a certainty, only the unnamable is eternal.

Most engineers understand that the software development world is fluid, and therefore they are often very accepting of change (and even deprecation). There’s only one area where engineers almost universally have trouble letting go, and Lao Tzu calls this out specifically:

Their own work.

Ironically, retaining one’s work is the quickest way to give it a short life. Transformation is eternal, retained work cannot be easily transformed… so instead it gets replaced.

Undocumented solutions can’t be easily extended or easily understood. Those solutions quickly become ugly, and the ugly gets reclaimed.

Hey Lao Tzu! Should I open source my work?

Only if you want it to continue.

But what about “Not Doing?”

Well, it doesn’t mean that the wise engineer is lazy. It means the wise engineer follows the tao. Transformation is going to happen, the wise engineer understands the transformations, and simply allows them to happen.

Sure, there will be effort involved in clearing the path- but this isn’t “doing.” The tao is doing the doing. By clearing the path for the tao, things get accomplished on their own. The engineer does without doing.

If you’ve ever fought for something or done something “against the flow,” you’ve experienced at least some of what Lao Tzu is describing here.

Very Often the project’s activities as a whole are anti-tao. In those cases, the wise engineer will go against the project’s conventions, therefore clearing a path for the tao to do many things. A project holding on to anti-tao things is just another form of possession, causing chaos and unproductive work.

Note that “letting go” does not imply abolishment of processes and tools — it means using processes and tools that follow the tao. In some cases, it may be that a project intentionally retaining a lack of process is anti-tao.

Choosing to not implement continuous integration, for example, makes the engineers perform tasks that could be automated. The engineers are now doing things that could be performed better by not doing them. Lao Tzu revisits this concept of not-doing often, and therefore we will be discussing automation often.

Similarly, the engineer advocates without advocating

By simply using the correct tools or concepts for the problem. If the thing requires advocation to be justified for use, it’s almost certainly not the time for it. Either the thing’s time has passed, or has not yet arrived.

Often, when it comes to advocating for something; “Better” and “worse” only exist to support each other. As such, the choice between two solutions is often irrelevant. The wise engineer does not spend time contributing to irrelevant discussions, they simply do the work and then let it go.

This is part of the Tao Te Dev series, read about it (and find more entries) here.