There seems to be a lot of confusion about this.

Test automation is any use of tools to aid testing. Test automation has been around since DAY ONE of the computing industry. And never in that history has test automation been an “automatic way of doing what testers were doing before”, unless you ignore a lot of what testers actually do.

For the same reason, a space probe is not “an automatic way of doing what planetary scientists were doing before”, but rather a tool that extends the reach of what scientists can do. Test automation means extending the reach of testers.

Test automation is not at all new. What’s comparatively new is the idea of a tester. Long ago, in the late 40’s, dedicated testers were almost unknown. Programmers tested software. Throughout the sixties, papers about testing, such as the proceedings of the IFIPS conferences, almost always assumed that programmers tested the software they built. Testing was often not distinguished from debugging. As larger and more complex systems arose, the idea of dedicated software testers came into vogue. In 1972, at Chapel Hill, the first conference on testing software was held, and the proceedings of that conference show that testing was beginning to be thought of as a discipline worthy of study apart from programming.

At that conference, I think they took a wrong turn. There was much hope and enthusiasm for the future of test automation. That hope has not panned out. Not for lack of trying. More for lack of understanding.

What they didn’t understand, and what many contemporary programmers and testers also don’t get, is that good testing is an inherently a human process– not incidentally, not accidentally, but INHERENTLY. It’s highly social and psychological. The more complex software is, the more important that humans engage intellectually to identify and solve testing problems. But the Chapel Hill conference was dominated by men trained as programmers and electrical engineers, not people who professionally thought about thinking or who trained people to think.

(Who did, you ask? Jerry Weinberg. His 1965 Ph.D. thesis on problem solving is fabulous. He had written The Psychology of Computer Programming in 1970, a number of papers about testing during the sixties, including a section on testing in his 1961 book, Fundamentals of Computer Programming. He taught problem solving classes during the 60’s too, culminating in his 1974 book Introduction to General Systems Thinking. I regret that Jerry didn’t keynote at the Chapel Hill conference, but he will at the next CAST conference, in Toronto.)

The idea of a dedicated trained tester is newer than the idea of test automation, but unlike test automation, it’s an idea that hasn’t been tried on a large scale, because tester training is so terrible.

Pretending that testing is a simple technical process of making API calls doesn’t make the boogie beasts go away. They are still there, Microsoft. My wife still needs me to troubleshoot Microsoft Office, a product produced increasingly, I’m told, by programmers who work intensively on test tools because they never learned how to test. (My colleague Michael Bolton recently ran a testing class at Microsoft, though, so perhaps there is hope.)

Test automation cannot reproduce the thinking that testers do when they conceive of tests, control tests, modify tests, and observe and evaluate the product. Test automation cannot perform sapient testing. Therefore, automation of testing does NOT mean automation of the service provided by the software tester.

In summary, test automation means applying tools to testing. Test automation is ancient, non-programming testers are a newer idea, but what the industry has not yet really tried, except on a small and local scale, is systematically training the minds of testers, instead of just calling them “test engineers” or “SDETs”, giving them tools they don’t know how to use, and hoping for the best.

(BTW, I’m a programmer. I was hand-coding machine language on my Apple II before I ever heard of things called “assemblers” that automated the process. I also ran the Borland Turbo Debugger test team on the Borland C++ project, in the early 90’s. Before that I ran a test tool development team at Apple Computer. When it comes to programmer testing, GUI test automation, and non-GUI test automation, I’ve been there and done that.

It is my experience of the profound limitations of test automation that makes me a bit impatient with the way new generations of testers and programmers who seem to think no one ever thought of test tools before they came along.)

Sometimes people hear about the Context-Driven School of Testing and tell me there’s no need for it, because nobody disagrees with the importance of context.

And then I read things like this from Alberto Savoia. I don’t know how to account for it, except to say that it’s the mentality that I’m fighting against. If you want to see an example of what I think is wrong with our industry, there you go. I’m going to start posting such examples more often, because I’m tired of hearing that I’m just exaggerating the problem. I’ve met Alberto. He’s a smart guy. I don’t know what happened to him, but I suspect he’s hanging around with insufficiently critical colleagues.

[UPDATE: Alberto says that he meant the post satirically (see the comment below). So, let me be a critical colleague for a moment and say I didn’t notice the satire. I bet a lot of other people won’t, either.

However, it may mean that his post is not the evidence I need. I better go find better evidence… stay tuned.]

We need to learn more about how and why some people fall for metrics-based, or artifact-based techno-faiths, instead of studying their craft. I hope more people speak up against them, as Cem Kaner has done in the comment he posted to Alberto.

It takes a certain kind of courage to say no to managing-by-numbers, because it seems so safe and easy to give in. It’s particularly challenging to say no when you are afraid for your job, but I know people who have courage like that. Jonathan Kohl, for instance. He quit a job once when he was asked to sacrifice his ethics for the convenience of a particular manager. I’m not saying everyone can and should do that– but the people who put professional integrity above quiet facilitation of insanity deserve our respect and gratitude.

Hey, somebody at AST must have read my blog when I coined the term “sapient testing“, because they named their magazine after it.

I’m still waiting for people to pick up on my other coinage: mythomimetic, which is an adjective meaning “not informed by experience or wisdom, but rather hearsay and wishful thinking.” I’ll use it in a sentence: “The speaker peppered his talk with mythomimetic cliches such as ‘you can’t control what you can’t measure’.”

Sapient testing is the antithesis of mythomimetic test automation.

O happy day!

Thanks to the tireless webmastering efforts of Scott Barber, thanks to the original efforts of my brother Jon, David Gilbert, Michael Bolton, and myself as organizers, and thanks to the contestants who participated, the full video and print record of the second CAST testing competition is now online.

Friends, this is a first. It’s the first complete, reviewable record of a serious testing competition. I conceived this in the hope that we would gather vivid examples of the testing craft that could serve as a teaching tool for new testers. I believe we succeeded.

There are videos of bug reports (most of them are great examples of how to crisply explain a bug to a manager or developer) and there are videos of test techniques (testers demonstrating how they go about finding bugs). The product was real. The developer of the product was one of the judges.

And NOTHING HERE IS CONFIDENTIAL.

This is what our craft needs if it’s going to get a lot better. We need role models; examples; demonstrations; realism; and lot less secrecy.

This is what the Association for Software Testing stands for. I’m proud to be a part of it.

I want to follow up on what I said about discipline in yesterday’s post. I said that discipline is “motivation without reason.” I stand by that, as far as it goes, but there’s more to discipline than that, and I want to tell the whole story.

The sense in which I am using the word discipline is the fourth definition in the O.E.D.: “A system or method for the maintenance of order; a system of rules for conduct.” Self-discipline means a way to keep yourself in order. To have discipline you need some idea of order, and some way of maintaining order.

By motivation without reason, I mean a way of compelling someone to act without appealing to their judgment or desires. “Don’t argue with me, just do as I say” is an attempt to invoke discipline. When my executive mind tries to force my sleepy body to get out of bed and go to work, it’s trying to maintain order in my life. From the point of view of my body, some outsider is telling me to wake up when waking up does not seem reasonable. Hence motivation without reason.

As I was saying yesterday, I don’t have a lot of self-discipline. In other words, I don’t go around with a strong and specific idea of what I should do at any particular time, and even when I do have a strong idea, I don’t generally force myself to do those things. What I do instead is I manage myself by a sort of “consensus” of my various parts. Sort of like a parliamentary system in my head.

If sometimes I look like I am exhibiting a lot of discipline, that’s probably not because I am controlling my wild sinning self with the iron bridle of wisdom. More likely, I’m just not experiencing any conflict about what I want to do. That’s what I meant about not needing discipline if you know what you’re doing. When all your parts are in harmony, order unfolds spontaneously and naturally. You don’t need much of a system to maintain order.

But getting to harmony can be challenging. It means, in my projects and in my life, I have to do a lot of wandering and playing and procrastinating until I decide what I really want to do.

I wouldn’t necessarily recommend that anyone else live this way– I often envy people who can point themselves in one direction with conviction– but wandering does have its advantages, especially for a tester.

I often consult on software process improvement. As part of that, I promote an idea called “heuristic process improvement”. Heuristic process improvement is different than the typical process improvement approach in that it centers on developing the skills of the people on the project, while developing heuristics (NOT rote procedures) to help them do that.

If you are taking a heuristic approach to process improvement, then you will not be treating people like little stupid robots, and you will not be suffering the dusty binder syndrome. If you have dusty binders full of procedures nobody references, just throw them away. Problem solved.

Trying to Lose Weight

Matthew Heusser recently blogged on his weight loss process, so I figured I’d share mine, too.

Back on August 6th, my father challenged me to lose 10 pounds. It was to be a competition. Dad suggested one strategy: go to bed hungry. He swears by it, apparently. That means no food after about 5pm.

I followed his advice, which turned out to be pretty easy. The trick is to be hungry, but not ravenous at bedtime. I also decided to walk a mile every day, which required me to use hotel fitness centers. I’ve always been reluctant to do that, but in the urgency of competition I overcame that initial reluctance.

The third thing I did was very important: I start tracking my LOW weights. In other words, if I weighed myself and I saw a new low score, then I recorded it. Otherwise, I ignored it.

At first that was all I did. I wanted to see if it would work. After three weeks, I started to see it work. After eight weeks, I was sure that it was working. Not only that, but if you look at the graph, the steady 1.5 pounds per week loss clearly began on the very day that I started! It had been working all along.

I have no particular self-discipline. So, what made me stick with the program? I think it’s a matter of developing my skill and perceptions. I never before directly perceived the connection between specific things I did (or didn’t do) and my weight. This process has made me pay attention to that connection. Weight loss is now a game, with rules I understand. It’s a game I think I can win, instead of an endless and meaningless slog.

This same kind of transformation has to occur in a software project for things to get better. People need to feel that learning itself is a game they can win, or else they turn away from it.

If you Know What You are Doing, You Don’t Need Discipline

Discipline, like faith, is something that doesn’t work for me. I just don’t live that way. Maybe I was was born without a certain gene that most other people have. To me discipline is motivation without reason, just as faith is belief without reason. You do something a certain way because… well, because you’re disciplined, not because it makes sense to do it that way. Discipline is great for computers and robots, or for people who are emulating computers and robots, but I prefer being in charge of my own life. Instead, I operate according to an unfolding emotional and rational narrative that some people call “free will” (I don’t believe my will is actually free, but it feels free, so I’ll go with that phrase for now). Self-discipline is outside of free will, so I have to reject it.

I don’t need discipline to walk to a door, open it, and walk through the door. I just need motor skills and the desire to leave a room. If it’s difficult to leave a room, I won’t leave it until my desire to leave builds high enough.

Similarly, I don’t need discipline to lose weight. I just need to understand the causes and effects and make use of them. My problem had been that weight loss and gain were mysterious to me, at first. Much of that mystery is now resolved.
I haven’t had a pizza since mid-August. I love pizza. This also is not self-discipline. I simply have become very aware of what cheese does to me. I avoid cheese the same way I avoid hitting a deer in the road, when one jumps out in front of me. Not through discipline, but through desire not to hit the deer.

Process Improvement

About 10 days after I started walking every day, I began to feel distinctly better when I walked. I almost began craving a walk each day. I began to walk longer distances. After three weeks, I noticed that after a long walk my hips didn’t ache so much, and my legs recovered much more quickly. One day in Lund, Sweden, two of my students found out I was exercising and offered to walk with me. One of them pushed me to walk six miles that day, something I had not done since high school. Another told me to read Body For Life, because it had been so helpful for him.

When I read Body For Life, I felt repelled by the author’s “you have to do it this way” style. He is one of those discipline freaks. Instead of following his instructions, as such, I combed through the book to find a handful of ideas I would try on my own terms. As I tried them and found that they seemed to work for me, I went back to find more.

This is an important part of heuristic process improvement: you don’t follow someone else’s ideas. What you do is make some else’s ideas your own, and then follow your own ideas. To do this you need to experiment until the ideas make deep sense to you. This is less efficient than blind obedience, but also more satisfying and authentic. In the long run, for complex cognitive tasks, I find that it’s a lot more effective to be self-directed in that way.

Even though I don’t do exactly what the Body For Life guy says, I have gotten lots out of reading his book, and I wouldn’t be surprised if I eventually pursued a program that is indistinguishable from the one he recommends.

I am 5′11′. I was 261 pounds on August 6th. Since then I lost 27 pounds. I feel much better. I look better. I think I look good enough for a man not hunting for a mate, but since I’m already on a roll I want to see if I can get down to 200.

(This article is adapted from work I did with Johanna Rothman, at the 1^st Amplifying Your Effectiveness conference. It’s never been widely published, so here you go.)

As a context-driven testing methodologist, I am required to think through the methods I use. Sometimes that means debating methodology with people who have a different view about what should be done. Over time, I’ve gained a lot of experience in debate. One thing I’ve learned is that most people have good ideas, but few people know how to debate them. This is too bad, because a successful debate can make a community stronger, while avoiding debates creates a nurturing environment for weak ideas. Let’s look at how to avoid the traps that make debates fail, and how to transform disagreement into powerful consensus.

Sometimes a debate is really part of a war. The advice below won’t help much if that is the case. This advice is more for situations where you are highly motivated to create or maintain a working relationship with someone you disagree with– such as when you work in the next cubicle from the guy.

Traps

• Conflicting Terminology: Be alert to how you are using technical terms. A common term like “bug” has different meanings to different people. If someone says “Unit testing is absolutely essential to good software quality.” among your first concerns should be “What does he mean by ‘unit testing’, ‘essential’, and ‘quality’?” Beware, sometimes a debate about definitions bears important fruit, but it can also be another trap. You can spend all your energy on them without necessarily touching the marrow of the subject. On the other hand, you can allow yourself to understand and even use someone else’s terminology in your debate without committing yourself to changing your preferred terminology in general.
• Paradigm Conflict: A paradigm is an all-inclusive way of explaining the world, generally tied into terminology and assumptions about practices and contexts. Two different paradigms may explain the same phenomena in totally different ways. When two people from different paradigms come together, each may seem insane to the other. Whenever you feel that your opponent is insane, maybe that’s time to stop and consider that you are trying to cross a paradigmatic boundary. In which case, you should talk about that, first.
• Ambiguous Metrics: Don’t be seduced by numbers. They can mean anything. The problem is knowing what they do, in fact, mean. When someone quotes numbers at me, I wonder how the metric was collected, and what influenced the people who collected them. I wonder if the numbers were sanitized in any way. For instance, when someone tells me that he performed 1000 test cases, I wonder if he’s talking about trivial test cases, or vital ones. There’s no way to know unless I personally review the tests, or conduct a detailed interview of the tester.
• Confusing Feeling and Rationality: Beware of confusing feeling communication with rational communication. Be alert to the intensity of the feelings associated with the ideas being presented. Many debates that seem to be about ideas may indeed be about loyalty, trust, respect, and other fundamental issues. A statement like “C++ is the best language in the world. All other languages are garbage” may actually mean “C++ is the only language I know. I comfortable with what I know. I don’t want to concern myself with languages I don’t already know, because then I feel like a beginner, again.” There’s an old saying that you can’t use logic to refute a conclusion that wasn’t arrived at through logic. That may not be strictly true, but it’s a helpful guideline. So, if you sense a strange intensity around the debate, your best bet may be to stop talking about ideas and start exploring the feelings.
• Confusing Outcome and Understanding: Sometimes one person can be debating for the purpose of getting a particular outcome, while the other person is debating to understand the subject better, or help you understand them. Confusing these approaches can lead to a lot of unnecessary pain. So, consider saying what your goal is, and ask the other person what they want to get out of the debate.
• Hidden Context: You may not know enough about the world the other person lives in. Maybe work life for them is completely different than it is for you. Maybe they live under a different set of requirements and challenges. Try saying “I want to understand better why you feel the way you do. Can you tell me more about your [life, situation, work, company, etc.]?”
• Hidden History: You may not know enough about other debates and other struggles that shaped the other person’s position. If you notice that the other person seems to be making many incorrect assumptions about what you mean, or putting words in your mouth, consider asking something like “Have you ever had this argument with someone else?”
• Hidden Goals: Not knowing what the other person wants from you. You might try learning about that by asking “Are we talking about the right things?” or “What would you like me to do?” Keep any hint of sarcasm out of your voice when you say that. Your intent should be to learn about what they want, because maybe you can give it to them without compromising anything that’s important to you.
• False Urgency: Feeling like you are trapped and have to debate right now. It’s always fair to get prepared to discuss a difficult subject. You don’t have to debate someone at a particular time just because that person feels like doing it right then. One way to get out of this trap is just to say “This subject is important to me, but I’m not prepared to debate it right now.”
• Flipping the Bozo Bit: If you question the sanity, good faith, experience, or intelligence of the person who disagrees with you, then the debate will probably end right there. You’ll have a war, instead. So, if you do that, in the heat of the moment, your best bet for recovery may be to take a break. When you come back, ask questions and listen carefully to be sure you understand what the other guy is trying to say.
• Short-Term Focus: Hey, think of the future. Successful spouses know that the ability to lose an argument gracefully can help strengthen the marriage. I lose arguments to my wife so often that she gives me anything I want. The same goes for teams. Consider a longer term view of the debate. For instance, if you sense an impasse, you could say “I’m worried that we’re arguing too much. Let’s do it your way.” or “Tell you what: let’s try it your way as an experiment, and see what happens.” or “Maybe we need to get some more information before we can come to agreement on this.”

Transforming Disagreement

An important part of transforming disagreement is to synchronize your terminology and frames of reference, so that you’re talking about the same thing (avoiding the “pro-life vs. pro-choice” type of impasse). Another big part is changing a view of the situation that allows only one choice into one that allows many reasonable choices (the “reasonable people can bet on different horses” position). Here are some ideas for how to do that:

• Transform absolute statements into context-specific statements. Consider changing “X is true” to “In situation Y, X is true”. In other words, make your assumptions explicit. That allows the other person to say “I’m talking about a different situation.”
• Transform certainties into probabilities and alternatives. Consider changing “X is true” to “X is usually true” or “X, Y, or Z can be true, but X is the most likely.” That allows the other person to question the basis of your probability estimate, but it also opens the door to the possibility of resolving the disagreement as a simpler matter of differing opinions on probability rather than the more fundamental problem of what is possible.
• Transform rules into heuristics. Consider changing “You should do X” to something like “If you have problem Y and want to solve it, doing something like X might help.” The first statement is probably a suggestion in the clothing of a moral imperative. But in technical works, we are usually not dealing with morals, but rather with problems. If someone tells me that I should write a test plan according to the IEEE-829 template, then I wonder what problem that will solve, whether I indeed have that problem, how important that problem is, whether 829 would solve it, and what other ways that same problem might be solved.
• Transform implicit stakeholders and concerns into explicit stakeholders and concerns. Consider changing “X is bad” to “I don’t like X” or “I’m worried about X” or “Stakeholder Y doesn’t like X.” There are no judgments without a judger. Bring the judger out into the open, instead of using language that make an opinion sound like a law of physics. This opens the door to talk about who matters and who gets to decide, which can be a more important issue than the decision itself. Another response you can make to “X is bad” is to ask “compared to what?” which will bring out the unspecified standard.
• Translate the other person’s story into your terms and check for accuracy. Consider saying something like “I want to make sure I understand what you’re telling me. You’re saying that…” then follow with “Does that sound right?” and listen for agreement. If you sense a developing impasse, try suspending your part of the argument and become an interviewer, asking questions to make sure the other person’s story is fully told. Sometimes that’s a good last resort option. If they challenge you to prove them wrong or demand a reply, you can say “It’s a difficult issue. I need to think about it some more.”
• Translate the ideas into a diagram. Try drawing a picture that shows both views of the problem. Sometimes that helps put a disagreement into perspective (literally). This can help especially in a “blind men and the elephant” situation, where people are arguing because they are looking at different parts of the same thing, without realizing it. For instance, if I argue that testing should start late, and someone else argues that testing should start early, we can draw a timeline and put things on the timeline that represent the various issues we’re debating. We may discover that we are making different assumptions about the cost of bugs curve, and which point we can draw several curves and discuss the forces that affect them.
• Translate total disagreement into shades of agreement. Do you completely disagree with the other person, or disagree just a little? Consider looking at it as shades of agreement. Is it total opposition or is it just discomfort. This is important because I know, sometimes, I begin an argument with a vague unease about someone’s point of view. If they then react defensively to that, as if I’ve attacked them, then I might feel driven firmly to the other side of the debate. Sometimes when looking for shades of agreement, you discover that you’ve been in “violent agreement” all along.
• Transform your goal from being right to being a team. Is there a way to look at the issue being debated as related to the goal of being a strong team? This is something you can do in your own mind to reframe the debate. Is it possible that the other person is arguing less from the force of logic and more from the fear of being ignored? If so, then being a good listener may do more to resolve the debate than being a good thinker. Every debate is a chance to strengthen a relationship. If you’re on the “right” side, you can strengthen it by being a gracious winner and avoiding I-told-you-so behavior. If you’re on the “wrong” side, you can strengthen the team by publicly acknowledging that you have changed you mind, that you have been persuaded. When you don’t know who is right, you can still respect feelings and consider how the outcome and style of the debate might harm your ability to work together.
• Transform conclusions to processes. If the other person is holding onto a conclusion you disagree with, consider addressing the process by which they came to adopt that conclusion. Talk about whether that process was appropriate and whether it could be revisited.
• Express faith in the other person. If the debate gets tense, pause and remind the other person that you respect his good faith and intentions. But only say that if it’s true. If it’s not true, then you should stop debating about the idea immediately, and deal instead with your feelings of mistrust. Any debate that’s not based on trust is doomed from the start, unless of course it’s not really a debate, but just a war, a game, or a performance put on for an audience.
• Wait and listen. Sometimes, a conversation looks like a debate, and feels like a debate, but is actually something else. Sometimes we just need to vent for a bit, and be heard. That’s one reason why being a good listener is not only polite, but eminently practical.
• Express appreciation when someone tries to transform your position. When you notice someone making an effort to use these transformations in a conversation with you, thank them. This is a good thing. It’s a sign that they are trying to connect with you and help you express you ideas.

Thanks to Michael Bolton, for plunging in at Eurostar after I had to cancel. He has blogged on it here and here.

For what it’s worth, this is the presentation I was going to give at Eurostar, before I had to drop out.

And interestingly, Matthew Heusser just blogged on one of my central ideas: that different communities who discuss testing often use the same words to mean different things. Fixing this is not, as many have suggested, a matter of arriving at common definitions, but rather arriving at common understandings, because just as people can use the same words for different ideas, they can also agree to the same definitions yet believe those definitions mean different things. Only conversations, examples, and shared experiences– in other words, going deeper, going meta, and grappling with some uncomfortable disagreements– can we hope to build a truly united craft.

That great clarifying conversation won’t happen anytime soon, and for a reason you might not expect: if we were to to go deeper, go meta, etc. we would discover that we don’t really know what we mean by our own words. I say this because I personally experience this syndrome on a regular basis. If you look at the history of the development of exploratory testing, you will see that Cem and I have tweaked our definitions of it quite a bit over the years. We do that because we are in a state of continuously field testing what we think we know about ET, and striving to polish our presentation of it.

A lot of development and research is still needed for the testing field to progress significantly beyond where is was in 1972 when Bill Hetzel published Program Test Methods. I just re-read that book, today. It’s sobering to see how much the ISTQB parrots platitudes from that much simpler time.

Recently I posted a sort-of attack on Jim Pensyl, who had posted a sort-of attack on my community. Then an interesting thing happened. He withdrew his blog post and called me on the phone. That was unexpected. Almost nobody de-escalates that way. The two normal responses are A) abandon the debate, or B) continue the debate until everyone is exhausted or a stable point of agreement or disagreement is achieved. Jim chose a third way C) transcend the debate by bidding for a better relationship with his opponent. I want to try C more often. C takes special skill and guts.

Jim and I talked on the phone for two hours about testing and context, and in that conversation I think we forged a collegial bond. I think I know what he’s trying to do, now, and I suspect I can be more a service to him than a hindrance; and he to me. Considering how I felt before the phone call, it’s a spectacular result.

Collegiality is much needed in our industry. And I’m not talking about mere politeness or live-and-let-live passive rivalry. I’m talking about people who do the hard work of creating connections with each other that allow for differences while also constructively questioning differences. This is a matter of chemistry, sometimes. There are people whom I have been completely unable to connect with, despite my best efforts. It’s also a matter of motivation, because best efforts take a lot of energy.

My favorite colleagues are the ones that know how to criticize me and aren’t afraid to do it. Steve Smith provides a great example. I’ve known Steve for 10 years.

This has been a pretty good year for me, in colleague recruiting terms. I’ve gotten to know two new systems thinkers, Ben Simo and Matthew Heusser. And two people I knew before, Karen Johnson and Antony Marcano, have revealed depths of wisdom and talent I had not expected.

One colleague whose ideas are beginning to command my attention is John McConda, who just wrote this wonderful post about collegiality. Check it out.

(I had written a critical analysis and response to a post by Jim Pensyl, AKA Jake Brake. Jim subsequently took down that post, and it seems the right thing to take down mine. However, I got two comments on my original piece, and I’ll leave those alone, especially the one by Steve Smith, a friend and colleague whom has always been a bellweather for me.)