Tao Te Dev 3: the actors & the informed

Not praising ability
ends competition

Not prizing possessions
ends theft

The engineer architects
by emptying actor’s minds
and filling their needs,
by limiting their scope
and strengthening their resolve.

The engineer helps actors lose everything
they know, everything they expect,

and prevents the informed
from doing anything.

Practice not-doing,
nothing is out of order.

We’ve talked about using tools that follow the tao — now we’re talking about building systems that follow the tao.

Lao Tzu has identified two core elements in the system we’re architecting — “the actors,” which are empty minded, and “the informed” which specifically are *not* actors, since they are prevented from doing anything.

The parallels to the two things we learned about in chapter one — the named things, and the unnameable tao — are obvious and intentional. For our system to follow the tao, it should be architected in the same way.

In our modern context, we can interpret these “actors” as functions, and the “informed” as data. It doesn’t matter what the system is; we could be writing OO software, a procedural program, or building a server — in all of these cases there are things that execute commands, and things that store information.

The implications here are pretty straight forward and make a lot of sense:

Functions (the actors)

Empty their minds.

Functions shouldn’t know anything. They shouldn’t access global variables, as that’s just a different way for a function to know something. A function should be called with all the information it needs, and not retain any information after it executes. This is sometimes called no-mind.

It’s important to consider that the thing that makes a function valuable is the fact that it’s empty and stateless. You can’t fill a pot unless you know it’s empty; you can’t reliably use a function unless you know it’s empty.

Filling their needs.

Since functions are empty, you must call them with all the information they will need. The architect should design the function to fail if it does not receive everything it needs.

Limiting their scope.

Another interpretation of this line is “weaken their wishes” — a function should do one thing. Extending a function to do multiple things causes confusion and weakens “resolve.”

Strengthen resolve.

Functions should be hardened, you should know without a doubt the information returned is correct.

Help <functions> lose everything they know, everything they expect.

You’re probably working on a system that hasn’t been built like this from the ground up. As such, it’s your job to help the functions reach no-mind. Additionally, Lao Tzu is warning us about poor design and implementation here — what a function says it expects isn’t always what it needs. Remove the functions expectations, and provide it what it needs.

Data (the informed)

Lao Tzu tells us to not let data perform actions. Makes perfect sense, the tao acts, the named things are manifestations of the work performed.

When a function is added to data, you end up with a function that violates no-mind. You don’t know if the pot is empty, and, worse, you don’t know what’s in the pot — and therefore you can’t trust that the pot does what you expect! If you ever find yourself needing to inspect (or set) local variables within a function before executing it, you’ve got a problem.

Many scripting languages mix data and functions together. These systems quickly become notoriously difficult to maintain as they scale — just look at anything written in perl or PHP. If you do need to use a scripting language, take the time to break up the data and functions. The best (complex) bash scripts have separate config files.

Higher level design

Lao Tzu also gives us some pointers on higher level design, explaining that no element in the system should be prized or coveted over others.

Ending competition.

You know that really cool piece of your software that everyone likes to work on because it does such cool things? Yeah, it’s actually no better than the logger that nobody works on. Stop praising the cool thing, and people will start working on the important thing — the whole system.

Ending Theft.

You know that singleton that every transaction goes through? It has something important. Make that something not important.

Not-doing

There’s the not-doing thing again. It means several things in this passage.

Clear the path and allow the tao to do things. You’re building a system- your design goal is to let the system run itself. It should function intrinsically, without any unnecessary interaction. The system should just run; things should just happen, without any fanfare, celebration, or credit-taking.

nothing is out of order. Not-doing in this case is also not-designing. There is a simple, clear design solution for this system. You should not design it, the system should design itself. Everything should easily fall into place. If the system does not self-design, then examine the constraints you are placing on the design and change or let go of them.

Defects typical arise when trying to force an unnatural pattern — since this system designed itself, functions intrinsically, and separates data and functions — nothing is out of order. There are no defects.

… Or if there are, at least they are easy to identify and clearly contained :)

Not just system design

All of this has applications in organizational structures, project management, and even management on a personal level. Our engineer in Chapter two becomes effective when not possessing, and clearing the path for the tao to do. This is how things are, there are empty actors who work with the tao, intrinsically producing and reclaiming the named manifestations we all see. When those actors attempt to retain those manifestations, things fall apart.

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