This is suddenly more relevant after Adam’s excellent post on Aristotle and software (and while you’re at it don’t miss There Is No Agile). The following is just an application of virtues to writing…and in my opinion, very relevant to the practice of making software.

Following from the assertion that you can apply writing advice to code…

Zen and the Art of Motorcycle Maintenance (book, wikipedia) is an exploration of Quality (wikipedia) (not in the sense of QA or building cars). This is a long passage from Chapter 17 – Phaedrus is teaching a writing course at a local college – one of my favorite parts of the book, it’s a model for examination that I keep coming back to. My comments follow at the bottom.

“I think there is such a thing as Quality, but that as soon as you try to define it, something goes haywire. You can’t do it.”

(continued after the jump)

…

But then, below the definition on the blackboard, he wrote, “But even though Quality cannot be defined, you know what Quality is!” and the storm started all over again.

“Oh, no, we don’t!”

“Oh, yes, you do.”

“Oh, no, we don’t!”

“Oh, yes, you do!” he said and he had some material ready to demonstrate it to them.

He had selected two examples of student composition. The first was a rambling, disconnected thing with interesting ideas that never built into anything. The second was a magnificent piece by a student who was mystified himself about why it had come out so well. Phaedrus read both, then asked for a show of hands on who thought the first was best. Two hands went up. He asked how many liked the second better. Twenty-eight hands went up.

“Whatever it is,” he said, “that caused the overwhelming majority to raise their hands for the second one is what I mean by Quality. So you know what it is.”

There was a long reflective silence after this, and he just let it last.

This was just intellectually outrageous, and he knew it. He wasn’t teaching anymore, he was indoctrinating. He had erected an imaginary entity, defined it as incapable of definition, told the students over their own protests that they knew what it was, and demonstrated this by a technique that was as confusing logically as the term itself. He was able to get away with this because logical refutation required more talent than any of the students had. In subsequent days he continually invited their refutations, but none came. He improvised further.

To reinforce the idea that they already knew what Quality was he developed a routine in which he read four student papers in class and had everyone rank them in estimated order of Quality on a slip of paper. He did the same himself. He collected the slips, tallied them on the blackboard, and averaged the rankings for an overall class opinion. Then he would reveal his own rankings, and this would almost always be close to, if not identical with the class average. Where there were differences it was usually because two papers were close in quality.

At first the classes were excited by this exercise, but as time went on they became bored. What he meant by Quality was obvious. They obviously knew what it was too, and so they lost interest in listening. Their question now was, “All right, we know what Quality is. How do we get it?”

Now, at last, the standard rhetoric texts came into their own. The principles expounded in them were no longer rules to rebel against, not ultimatums in themselves, but just techniques, gimmicks, for producing what really counted and stood independently of the techniques — Quality. What had started out as a heresy from traditional rhetoric turned into a beautiful introduction to it.

He singled out aspects of Quality such as unity, vividness, authority, economy, sensitivity, clarity, emphasis, flow, suspense, brilliance, precision, proportion, depth and so on; kept each of these as poorly defined as Quality itself, but demonstrated them by the same class reading techniques. He showed how the aspect of Quality called unity, the hanging-togetherness of a story, could be improved with a technique called an outline. The authority of an argument could be jacked up with a technique called footnotes, which gives authoritative reference. Outlines and footnotes are standard things taught in all freshman composition classes, but now as devices for improving Quality they had a purpose. And if a student turned in a bunch of dumb references or a sloppy outline that showed he was just fulfilling an assignment by rote, he could be told that while his paper may have fulfilled the letter of the assignment it obviously didn’t fulfill the goal of Quality and was therefore worthless.

Now, in answer to that eternal student question, How do I do this? that had frustrated him to the point of resignation, he could reply, “It doesn’t make a bit of difference how you do it! Just so it’s good!” The reluctant student might ask in class, “But how do we know what’s good?” but almost before the question was out of his mouth he would realize the answer had already been supplied. Some other student would usually tell him, “You just see it.” If he said, “No, I don’t,” he’d be told, “Yes, you do. He proved it.” The student was finally and completely trapped into making quality judgments for himself. And it was just exactly this and nothing else that taught him to write.

Up to now Phaedrus had been compelled by the academic system to say what he wanted, even though he knew that this forced students to conform to artificial forms that destroyed their own creativity. Students who went along with his rules were then condemned for their inability to be creative or produce a piece of work that reflected their own personal standards of what is good.

Now that was over with. By reversing a basic rule that all things which are to be taught must first be defined, he had found a way out of all this. He was pointing to no principle, no rule of good writing, no theory — but he was pointing to something, nevertheless, that was very real, whose reality they couldn’t deny. The vacuum that had been created by the withholding of grades was suddenly filled with the positive goal of Quality, and the whole thing fit together. Students, astonished, came by his office and said, “I used to just hate English. Now I spend more time on it than anything else.” Not just one or two. Many. The whole Quality concept was beautiful. It worked. It was that mysterious, individual, internal goal of each creative person, on the blackboard at last.

Similarly, code doesn’t flow out of physics-like laws – it’s rooted in the messiness of cognition and creativity, just like writing. Everyone knows what good code looks like, but you couldn’t make that sense into an algorithm.

And somewhere in there is a great retrospective format that could be used again and again.

He singled out aspects of Quality such as unity, vividness, authority, economy, sensitivity, clarity, emphasis, flow, suspense, brilliance, precision, proportion, depth and so on

We have those in software (virtues): modularity, not-repeating-yourself, high-cohesion-low-coupling, simplicity, “readability”, what Tim Berners-Lee lists, and many others.

Edward pointed out the great article by Kevin Matheny, featured in BusinessWeek, on Agile, and our experience on BestBuy Remix.

I’d like to highlight this passage:

Trust is tied closely to how you deal with change. Often, extending trust is hard for businesspeople working on technology projects, because we don’t know how to do the work. We often look to the documentation — requirements, design specifications, and the like — to give us the feeling of control over the outcome. Don’t bother. If you can’t trust your team to deliver, you have the wrong team. Find people you can trust, and then let them do the work. Talk every day, and make sure that the development team has direct access to someone who will be using the product every day after release. For Remix, we’ve never had a formal project plan, never had a requirements-gathering session, never created a requirements document. We chose the right partners, told them what we needed, and got to work. We have control over the outcomes, but we’re not worried about trying to control the details of how we get there.

Of course without trust, any project – “agile” or not – is at risk. But practices typically associated with agile let you go further with trust: everyone is in close communication*, and all levels of the project – from test-driven code written by developers, to regular demos to the client of the latest features – are oriented around fast feedback.

In other words, you the customer trust us in part because what we’re doing is visible and tangible to you. If we’re going in a direction you didn’t intend, or what the team planned a few weeks ago just doesn’t seem relevant anymore, we all talk and we correct course.

* for close communication, see Pivotal Tracker

Here’s a good, quick read. It got its start about 10 years ago:

http://www.w3.org/DesignIssues/Principles.html

Topics:

• Simplicity
• Modular Design
• Tolerance (”Be liberal in what you require but conservative in what you do”)
• Decentralization
• Test of Independent Invention (”If someone else had already invented your system, would theirs work with yours?”)
• Principle of Least Power

When you’re heads-down doing Agile or OOP sometimes you find yourself accidentally assuming that certain useful general principles are special to what you practice – when the truth is they’re probably not even unique to your discipline, and some Greeks wrote them down around 500 BC.