9. Enough

Filling to the brim is not more
than what was already enough.
Sharpening the blade
makes it easier to dull.

The more possessed
the harder it is to protect.
Possession, pride, arrogance
bring their own punishment.

Complete your work, then step back.
The only path to serenity.

Projects *love* to retain stuff. We discussed earlier that possession isn’t good, and we re-enforce that notion here with some new angles on it. This passage is awesome because it applies to so much – let’s start with a concrete example, the ever-present storage problem.

Filling to the brim

Probably the signal biggest problem an IT department needs to work out is how much storage to have (and what form of storage). We always discuss storage requirements, but we never discuss how useful the stuff we’re storing really is.

Fact is, in almost all cases, the only useful data is the most recent results of an action – be it the builds, production logs, or even documentation – the usefulness of retaining data drops off exponentially as it ages.

The costs of retaining it, however, increase exponentially . The more is possessed, the harder it is to protect. Backups get more costly and time consuming. Data that’s sensitive must be protected even if it’s old, that protection takes effort. Finding what you need is harder.

The greatest sin an organization can commit is not having an aggressive data deletion scheme – not allowing the bits we no longer use to be reclaimed. There’s great benefit in retaining as little as possible, which is the exact opposite of the “just in case” retention policy of most organizations.

Another interpretation of this passage includes “Chase after security and your heart will never unclench.” The project looking to retain everything is focused on fear – even if the project doesn’t fully realize that. An indicator of this is a project discussing and actively extending the limits of their data retention (and therefore the perceived security that retention doesn’t actually provide).

The project looking to not accumulate won’t be focused on these things and therefore can spend time on things that are actually important, without wasting time on the non-return effort of possession.

Of course, all of this works on other levels also-

Project policy and procedure overload

Another form of “stuff” which can easily be filled to the brim is the policies and procedures of the project itself, the over-documentation and over-enforcement (and certainly over-retention) of policies and procedures. In the end, this is another form of project fear, seeking security via possession.

Often, new policies are instituted in order to “improve” the organization, the sharpening of the blade that we all hear about at corporate all-hands meetings. The problem is, the more that we add to any procedure seeking to improve it, the easier it is for that procedure to fall in on itself. The more we sharpen, the easier to dull.

This isn’t saying that procedures shouldn’t be improved – it’s saying that improvement shouldn’t have to be forced and is almost never additive. Real improvement to a process occurs when it’s brought closer to the tao – when that process is made simpler and more effective, not more complex and easier to break (often in the pursuit of false security). Complexity weakens resolve, in code and in procedures.

The more of these policies that exist, the harder they are to protect (enforce). Have as few policies and procedures as practical, and when improving, only simplify. Possession brings it’s own punishment.

You should never be satisfied with your policies and procedures, the fact they exist at all indicates things aren’t perfect. Prideful things aren’t allowed to transform, therefore the project will suffer the difficulty of living with an anti-tao policy until it is ignored and/or replaced. Drop the pride and allow your policies and procedures to change as needed. Pride brings it’s own punishment.

Your project isn’t the only project in the world; you can look to others and learn from them, even if they are seemingly doing less or are less organized, they aren’t less good. Your project is no better than theirs. Arrogance limits where you can gain wisdom, and means that real solutions may be missed. The best case scenario for the project when a solution is missed is the pain of living with a less-tao solution. The worst case scenario is the project being reclaimed and replaced by one that’s willing to learn and transform. Arrogance brings it’s own punishment.

Engineer’s self overload

All this applies directly to us, too.

Engineers have a tendency to over-collect information at the beginning of an effort, in an attempt to “understand the problem.” Some of us need to learn to figure out when we know enough to get started. Often that doesn’t mean filling to the brim.

When we do collect a lot of information up front, we need to be smart enough to pair it down to the critical elements. Considering too much when building a solution often negatively impacts the quality of the solution, due to additional unneeded complexity.

We train in order to strengthen our skills, but when we train more than we do, we end up less effective. Always sharpening makes us dull. There’s a point where it’s time to put down the documentation and just try it.

As previously discussed, it’s important to do and let go. The more product areas or code the engineer tries to possess, the harder it is for the engineer to defend those possessions. For many of the same reasons above, Possession, Pride, and Arrogance bring their own punishments.

Complete your work, then step back.

The “definition of Done” is a core concept in current Agile methodologies, and I feel the focus on “Done” has a lot to do with what Lao Tzu told us centuries ago.

Several other interpretations talk about “Accomplishing great deeds and acquiring fame” when talking about completing the work. I think this helps make the step back stronger. It’s not just stepping away from the now completed work and moving to the next thing, it’s stepping away from the associated “fame” that comes with completion – stepping away from the kind of situation and thinking that inspires holding on to the completed work (possession), pride, and arrogance which set us up for future issues.

Agile tells us to do everything that’s related to a story before calling it Done, as a way to make it easier to let go of that story and move on to the next one. Agile is using the definition of Done as a way to break possession. One can hope that by breaking possession, we won’t fall into the traps of pride and arrogance.

Advertisements

One Comment Add yours

  1. Pingback: 10. – tao te dev

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s