Three In The Morning

Between 1991 and 1993, I went through a period of time in which basically all I read were books on Chinese philosophy. From Zen, to Taoism, to books by Bruce Lee (which on first glance are about fighting, but really have a whole other level to them), I read everything I could get my hands on. I have boxes upon boxes of books in the basement ranging from Zen in the Art of Archery, to Zen Driving. I’ve got more of these books than I can count stored down there.

I have been mulling over a presentation that I have to give in a few weeks and have written and rewritten it a million times, trying to figure out how to communicate some ideas while not being sure what the best way to communicate them would be. I have definite ideas about certain things and find myself sometimes being unable to adapt myself to things that do not subscribe exactly to the way I am holding the image in my head. This has been one of my big challenges while moving from a technical role to management. Depending on where certain people are coming from, they may phrase something differently than I have in my head and I will spend more time arguing with them than thinking about the similarities between what they are saying and what I have in my head. The reverse tends to happen as well.

By chance, I picked up a copy of “The Way of Chuang Tzu” that I have had sitting on my bookshelf for over 10 years now and started reading it on the way to Gameworks yesterday with the kids. I came across the following passage called “Three in the Morning”. Since it was so applicable to what I have been struggling with lately, I thought I’d post it up here. This version was pulled from TrueTao.org, as for some reason I like the way it is written in this interpretation better than the interpretation I have in my copy of the book.

Here it is, for your meditation and enjoyment:

When you break something up, you create things.
When you create something, you destroy things.
Material things have no creation or destruction.
Ultimately these concepts connect as one.

Only the enlightened know that they connect as one,
So instead of debating this with your preconceptions,
Approach it in an ordinary way.

Those with this ordinary approach, simply apply the idea.
Those who apply it, connect with it.
Those who connect with it, attain it.
This easily attained understanding is not far off.

It all flows naturally.
To attain this state and not even know it,
Is what we would call Tao.
To exhaust your mind trying to unify them,
And not realize that they are the same,
Is what we we would call “three in the morning.”

What is this “three in the morning”?

A man who fed monkeys with chestnuts said to them:
“Three portions in the morning, four in the afternoon.”
All the monkeys got angry.

The man then said:
“Alright, four in the morning and three in the afternoon.”
All the monkeys were pleased.

The food and the quantity had not changed,
And yet resulted in anger and happiness,
All because of the different arrangement.

Therefore the sages incorporate the two concepts,
Don’t even try to debate truth and falsehood,
And maintain the principle of natural balance.
This is what we would call the dual approach.

Whats the lesson here? People are irrational by nature. They may argue with something when phrased one way and agree with it if you just change it enough that it seems like they are benefiting more from the new perspective than they were from the old, because when it all comes down to it, people want to know what is in it for them and want to maximize the benefit they receive.

What the monkeys received overall did not change from one proposal to the next, but they felt like it had.

The hard thing for me is communicating things in a way that non-technical people can understand. I may be communicating something that absolutely has value for a business person, but the benefit gets lost because I’m not talking to them in their language. They can’t see it. At the same time, when they try to communicate value to me, I can’t see it because I am not making an effort to communicate with them from their perspective – I have my own.

But the benefits are the same from both.

This was a really good thing to run into at a perfectly applicable time. I really have to learn to communicate in such a way to get the point across to others, rather than only being able to communicate things in the way I understand them.

Thats the lesson for this weekend.

Slashdot Goes Tableless

I read over on Dougal Campbell’s blog that Slashdot has moved to a tableless design using HTML 4.01 and CSS. The announcement on Slashdot itself also explains why they settled on HTML 4.01 rather than going full-tilt XHTML.

Interestingly enough, they are also planning on holding some kind of competition to redesign the Slashdot theme and have made their CSS available for download to enable people to participate.

Back in June I wrote two articles (Learning CSS and Finishing the CSS Prototype), about my first foray into CSS, spending a week learning as much as I could about CSS using the conversion of my companys home page to CSS in order to present the technology to our leadership team as a way to reduce page download time and reduce labor when changing layout. In one of those articles I stated that I had not been as excited about learning a new technology since starting to learn Python a year or two ago. I still feel the same way. Its very cool to see large sites like Slashdot taking the leap to complete CSS implementations. The additional separation of presentation from the markup code is an exciting concept, allowing you to both reduce code size and reduce the labor it takes to retheme your site when your branding changes without completely gutting the site each time you need to retheme.

We’ve started our conversion, incrementally, when we are touching the pages. The initial results look really good. The mandate has been made that new pages be developed with CSS implementations rather than the plethora of table and spacer tags that choke the pipe for our customers. We’re on our way. So the initial results of the prototype proved the point sufficiently.

Still, I hope bigger sites comparable to Slashdot keep making the switch, and announcing that they are doing so, so that more of us have ammo to make a move like this and spend the time to do it. Many companies just don’t want to make the leap until they see other comparable sites making it first. Its painful to do, but once its done, the labor savings and additional possibilities from a design perspective will definitely be worth it.

The other lesson from this one is one that Joel Spolsky talked about in one of his articles, Getting Things Done When Your Only A Grunt. One person can make a difference. You just have to care enought to do what it takes to make your point.

Ken Schwaber and Scott Ambler on ITConversations

I found two excellent lectures on IT Conversations that I would like to recommend to people looking at how to learn (or justify) agile development methods. The first lecture was given by Ken Schwaber, the creator of the Scrum project management methodology, called You Thought it was Easy: Wrestling Gold from Today’s Software Projects. In this 40 minute discussion, Ken explains what Scrum is and how it works. Its a very informative lecture that has helped a lot in giving me additional ways to try to explain the advantages of Scrum as a project management methodology.

One of the interesting points that Ken brings up is that when you introduce an empirical model like Scrum, all of the things that have been wrong in your environment for such a long time come to the surface and have to be dealt with. We have definitely seen this in our environment and it has caused some discomfort on the team. For me, its very nice to have a lecture like this that I can refer team members to that explains that this is a normal part of the process. It is, however, extremely difficult to explain to some that the problems we are seeing have been around for quite a long time, but that we have been unable to quantify them until implementing Scrum.

The second lecture was given by Scott Ambler and is called Are you Agile or are you Fragile in which Scott tries to explain the advantages of Agile methods and answer some of the arguments one would get in justifying using Agile methods on actual projects. There are a couple of interesting things about this lecture. First, he runs it as an agile project, eliciting “requirements” or topics from the audience and having them prioritize them. Secondly is the passion in which Scott talks about Agile methods and his no nonsense way of explaining the advantages.

This lecture gave me a great quote that stuck with me. “A new requirement is a competitive advantage – if I can act on it”. I found this to be a brilliant reframe of the common objection to changing requirements that happens on teams which have been “raised” on the waterfall type of approach where requirements are finalized and cannot change without having been “wrong” in the first place. This lecture is a long one, weighing in at one hour and 55 minutes.

For those teams out there that are attempting to implement agile methods in an environment that has been historically waterfall and “predictive planning” based, these two lectures are definitely something you should check out.