Tuesday, November 18, 2008

Bored with the rhetoric

During election time, I often find myself contemplating argumentative techniques as I watch the politicians do battle for votes. But it's not electioneering that I'm sick of - when you don't have a TV, live in the mountains, and avoid USA Today, you can moderate your intake pretty easily. It's programmer rhetoric that's gotten me down. We're an opinionated bunch, we developers. I'd like to think there's some relationship between an enjoyment of discrete mathematics and a healthy passion for the subtleties of logical argument, but rationality doesn't always reign supreme. Here's a few examples that I've seen over the past year:

Using the phrases "I'm just being pragmatic", or "my solution is the simplest thing that works" to convince someone the merits of an idea. If you respect the person you are arguing with, and you are both aiming for a pragmatic and simple solution (as we all should be), then these statements are not helping. You're trying to discredit the other person's argument by implying that they are not pragmatic, or their solution is too complex. If the two of you agree that one solution is simpler than the other, then focus on why the simpler solution is adequate.

"But that's not Agile"I see a repeating pattern in software. Over time, we learn from our mistakes. Out of this learning, we come up with some high level goals (such as the four specified in the Agile manifesto). We then develop some set of practices to help guide people in achieving the goals. Then we follow the practices, refining them a bit to make sure the goals are met. But then, after time, we get caught up in the mechanics of the practices, and forget what the goals are all about. Practices are often much easier to understand. Often when I hear "but that's not Agile", it's to do with a practice. It might be "If a story is more than 3 lines long, we're not being Agile". But the manifesto goal is "Customer collaboration over contract negotiation". So long as we're not sacrificing customer collaboration with our 4th line on our story, then it shouldn't be a problem. And if you think we're hurting our customer collaboration, focus on that in the argument.

The Logical Fallacy"see, that's why we need continuous integration"This quote comes from me. I said it. I use programmer rhetoric too :( But I'm trying to get better... Anyway, I was arguing with my project manager about our need for continuous integration. We were developing on macs, and deploying to linux. We had a problem that was only exposed on linux. I had been advocating for a linux machine to run Cruise Control. So I jumped on the chance to further my argument. "See, that's why we need continuous integration". But my project manager called me out on it. He's a smart guy. And he said "So are you telling me that you would have had a test that exposed this problem?". I had to admit that no, I wouldn't have. I'd used a logical fallacy. Yes, continuous integration helps expose bugs. Yes, we had a bug. Both of those statements are logically correct. But it does not follow that continuous integration would have exposed this bug. Shame on me...

As Steven Levitt says in Freakonmics, professionals tend to take advantage of their specialised knowledge to better themselves. He's talking specifically about realtors in one chapter, but programmers aren't above this behaviour. The skills and knowledge that we have gained in order to do our jobs is pretty rare, and we're privileged to be in the position we're in. But all too often I see developers taking advantage of their specialised knowledge during an argument and misleading their opponent by talking about something that the opponent doesn't understand. If you want to win the argument, explain your reasoning in a language that your adversary understands.

And yes, I do understand the irony of using rhetoric to describe my frustration with rhetoric. But I swear it's for good, not evil.