Undercutting Your Own Argument

by Jacob 7. June 2007 17:29

Ironic door sign There's a reason that my personal blog is named The Rabid Paladin—I form opinions easily and express them strongly, even as I attempt to maintain an even keel through my sense of integrity. What this means is that on those occasions when I enter an argument with the purpose of informing and/or convincing others, I try to remain open to valid points from other perspectives and the possibility that I might be wrong.

Letting Bias Show

Too often, people arguing their case will paint alternatives in as bad a light as possible—perhaps believing that their misrepresentations make their arguments stronger. The true effect is that it weakens their argument when it becomes clear that their biases have colored their analysis. Technologists are particularly ill-served by this tendency. Computers function logically so there's an expectation that those who are able to understand and manipulate computers will be similarly logical.

So it's often disheartening to me when I see blatant bias in developers and other technologists. Note, I'm not talking about people whose opinions differ from mine or who value some aspects differently and thus favor other technologies or solutions or approaches. I'm talking here about people who want things to be a certain way and let that desire cloud their judgement and rhetoric.

There are a couple of good examples of this at work in the comments to my post about Microsoft. I actually struggled about doing this in a full-blown post because I don't want to pick on people who took the time to post here. I want to encourage people leaving feedback and don't want to give the impression that I'm trolling my own blog for people to make fun of. That said, the bias against Microsoft is something that I've been thinking about a lot lately and this gives me an opportunity to illustrate things that I find off-putting.

Sloppy Equations and Florid Adjectives

The very first comment is by "LKM".

How about "they engaged in blatantly illegal business practices in order to destroy their competition"?
It's not like they were not found guilty of this by a US court.

Now, it's not clear if the reference is to Microsoft being a monopoly or the broader point of Microsoft being evil, but the terms used here clearly show a bias against Microsoft. First off, being found guilty of violating a U.S. law is hardly proof of being either evil or having a monopoly. Name one company Microsoft's size and age that hasn't been sued successfully.

The cold, hard, unfortunate fact of corporate life in the U.S. is that large companies make attractive targets for lawsuits from individuals, corporations, and government entities. Being ethical (or "not evil") isn't protection from being sued, nor is it a shield against conviction. The worst you can say about Microsoft from the fact that they were sued successfully is that they were sued successfully. Any further conclusions that you wish to draw from that conviction still have to be backed up by reason and logic.

Second, LKM's description of Microsoft's business practices as "blatantly" illegal is an example of an intensifier that ends up undermining instead of emphasizing. If their practices had been blatantly illegal, then the trial would have been extremely short if it had gotten to court at all. Microsoft didn't get to where they are today by being stupid about how they spend their money and there's nothing dumber than trying to defend the indefensible.

Frankly, describing Microsoft's actions as blatant also indicates LKM's opinion of those who don't agree. Used maliciously, framing it that way could be seen as a way to cut off debate by implying that you'd have to be blind to disagree. I'm not saying that LKM was deliberate in this or that it was intended as such. Still, this is a form of what I meant in the conclusion of my prior article when I say that painting Microsoft's users and/or supporters as stupid is not a useful way to convince them that you are right.

Ignorance and Hyperbole

Syd from Fairground Town is a little more articulate, but in the end comes off as much more biased.

For me, the incident which summed-up MS was Genuine Advantage. It wasn't the fact that they did it, which I guess was fair enough (what with it being their software 'n'all) but their spokesperson on BBC Radio telling us that "Customers have been crying out for a way to know if their copy of Windows is genuine." This was a breath-taking "big lie", worthy of Goebels, and it was the "last straw" that made me shut down my ten-year-old Hotmail account and buy a Mac.

The beginning here seems like Syd is going to be reasonable. It's a good first step to acknowledge that someone has the right to do something even if you (presumably) disagree with them doing it. He undermines this by displaying both ignorance and extreme hyperbole further in, though.

Now, I didn't hear the spokesperson in question so I can't properly contextualize the quote Syd offers, but I'm willing to bet that Syd doesn't work in a large IT department—a context where the spokesman might actually make sense. While it may be the case that BBC Radio failed to contextualize the quote he heard (making his initial ignorance not his fault), it's important for someone actually trying to be reasonable to look for how a statement that seems so ludicrous actually could be true. Few people lie deliberately or blatantly in a forum guaranteed to reach millions of people. Microsoft's spokesman had to have had a reason for this statement, even if you end up disagreeing with it. Understanding what that reason is should be the very first step in an incident you plan to describe as motivating some action on your part.

Personally, I have worked with a couple of companies where one of the largest headaches of the systems guys was tracking licenses so I understand where the spokesman could be coming from. Licensing was a particularly onerous task at XanGo because our growth was so extreme. The anti-piracy folks at the BSA have managed to win enough cases and levy heavy-enough fines that companies really don't want to go through the expense of an audit that finds that they are out of compliance. One aspect of Genuine Advantage includes the ability for sysadmins to track this automatically and I suspect this is what the Microsoft spokesperson was talking about.

But really, Syd loses me entirely with the Nazi reference. As we gain distance from the horrors of WWII, people seem to be increasingly willing to use Third Reich references to vilify people they disagree with. It makes me wonder if they know anything about the reality behind those events except as a way to put their opponents beyond the pale. It's an obnoxious rhetorical trick and one I've come to despise. I'm to the point any more where I automatically discount anyone making a comparison to anything Third Reich, even if I suspect I might agree with them. The strength of the hyperbole automatically disqualifies them as someone I'm willing to take seriously, let alone support. I mean, if you break it down, Syd is implying that a spokesman for Microsoft is on the same level as someone who covered for the wholesale slaughter of men, women and children.

This comparison is so extreme that it leads me to suspect not just Syd's sincerity but his veracity as well. I suspect he already owned a Mac and already intended to shut down his Hotmail account (assuming he had one). In fact, it's reminiscent of the rhetorical device where a commenter will claim an affiliation they don't have in order to lend weight to their statements (like someone describing themselves as a lifelong member of a political party even as they regurgitate the talking points of the opposition).

Passion, Conviction, and the Right to be Wrong

Now, I'm not saying that either commenter had no right to their opinion or passion. I'm too passionately opinionated myself for that to fly. What I'm saying is that having passionate opinions doesn't mean you should paint counter arguments as less than they are. Doing so diminishes all participants in a discussion, starting with yourself. Indeed, both Syd and LKM ended up undermining themselves to me more than they did Microsoft with their arguments.

I like to tell people that I maintain the right to be wrong. I know that I've been wrong in the past (with a stellar example on this blog just last week). I know that I'll be wrong in the future. Knowing this, I have very few convictions that aren't open to reasoned argument. But please note the modifier there. I don't think that I'm alone in being put off by argumentation that is long on passion and short on logic. Particularly when the terms of those arguments attempt to railroad me or use rhetorical trickery.

And I continue to believe that implying someone is blind, stupid, or allied with murderers is a poor way to convince them to take you or your arguments seriously.

Tags: , , , , , ,

General IT

Are We There Yet?

by Jacob 29. January 2007 17:19

"So when will you be done with this development project?"

I don't know about you, but I hate this question. There simply is no good answer for it. It seems like such a simple question with a simple DateTime valued answer. One of these days I swear I'll answer with, "Oh, I'll be done next Tuesday at 2:34pm." just to see what happens.

And seriously, businesses hate that we have such difficulty answering the question. It seems perfectly reasonable for them to want to know when they can plan to have the new processes that they know they desperately need. Developers demand high salaries and are ostensibly professionals, they should be able to give a professional answer, right?

The Road is Well Paved

The thing is, software development is a lot harder than people expect it to be--and this includes software professionals. Even simple software projects can run afoul of hidden complexities that can destroy well meaning estimates and make everyone unhappy. And no matter how you hedge your answers, people simply don't remember all your caveats, maybes, and what ifs that you use to indicate uncertainty.

The end result is that developers seldom make their ship-by dates and companies become disillusioned and impatient with all software development. That's not helpful for anybody, but it's pretty much the rule anymore.

And the fact of the matter is that the vast majority of developers (and development managers) never learn how to answer the estimate question. They'll move from company to company, repeating the cycle of hope, suspicion, and disappointment over and over again. Which works well enough for the developers in the boom times when the demand for development is so high that mildly talented house plants can get hired as developers.

So a lot of people are making the same mistakes over and over. Businesses can be excused for assuming that this is simply the way things are and feel confident in their distrust of software professionals. They've been there, done that, bought the t-shirt.

Paying the Toll

This environment causes developers who care about these kinds of things a lot of heartburn. Everyone pays for the ongoing cycle of disillusionment. I believe that this is what really prompts posts like the recent ones from Ted Neward talking about professional ethics. And I've been known to throw my own hat into the ring as well.

We get tired of paying for the sins of those who have gone before. And I'm not referring to the messed up legacy code we stumble into, either. Frankly, messed up code is the least of your problems coming into a situation with a client who has been burned by previous developer promises. Companies that have had deadline after deadline missed have a degree of mistrust that is very hard to overcome.

We pay for this distrust in a hundred different ways. The thing is, trust is a paying commodity in business. Working with partners you trust means a whole lot of overhead you can simply skip. An analogy: if I trust a plumber to fix my sink quickly and professionally, I can go get a burger and leave him to it. It's only when I don't have that trust that I have to pay the additional overhead of having someone I do trust watching to make sure he's not napping under the sink.

Want to see a business manager go into a dreamy fantasy? Ask them what it'd be like to be able to trust their software developers (in house or not). The more experience they've had with developers the more intense the fantasy.

The Rubber Meets the Road

We have a couple of areas of friction in businesses that exacerbate this situation. The main disconnect with business managers is that we have borrowed terminology and tools from other disciplines without understanding that our processes are fundamentally different. It's tricky because the temptation to use manufacturing terminology is immense. After all, we are creating a product of sorts. This makes so much sense on an intuitive level that it's hard to realize that the comparison is misleading and potentially dangerous.

I wish we could retrain everyone to make analogies to other business specialties. Scientific research or law come to mind as potentially useful analogies because both are similarly plagued by the impact of unique situations, changing ground rules, and unforeseen complexities. It would be interesting to investigate how managing software development like a patent application or drug research would change how we look at the problems involved. We might have stumbled onto iterative cycles and responding to altered requirements a whole lot sooner, for example.

Paying Attention

The real problem, though, is that most developers (and even most development managers) don't take the time to learn about common friction points. Nor do they take the time to build relations with their business counterparts so that you have some political capital (aka trust) to use when it is needed. It's easy to forget that much of the progress in software development practices are pretty recent in terms of business processes. After all, business managers don't move at the speed of light and changes tend to take time to penetrate those layers.

Which means that a whole lot of industry advances aren't even theory yet in the board room.

And the fact of the matter is that you cannot expect a business manager to understand what makes Agile practices work. Or the reason that strong unit testing saves time over the long run even though it takes more time up front. Learning to communicate at a level that is sufficiently detailed for smart business decisions without getting bogged down into the jargon inherent in any specialty is an invaluable skill, and one best learned earlier than later. That means thoroughly understanding those theories yourself--not just on the surface or in buzzword compliance. It also means learning to communicate that understanding from orbit, 30,000 ft, 5,000 ft, and right on the ground. This is hard to do. It takes practice. It also takes exposure to business manager types. I'm not sure which is harder...

Something to think about, though: not learning this skill leaves you at the mercy of those who do learn it.

My point, though, is that it takes both. You have to learn your profession so thoroughly that you can deconstruct its "best practices" ("design patterns", whatever) and rebuild them from basic principles on the fly. AND you have to learn to communicate that understanding comfortably to people of varying familiarity with software development in a business environment.

That's what it takes to be a true professional. It's easy to let those two skills fall out of balance. Individuals who understand both are invaluable to a company. Also rare. Companies who discover someone capable of both are often surprised at how much smoother things run with that person placed where they can do the most good--a point Jeff Atwood's latest on becoming a better programmer drives home.

So I don't have a formula for quick and accurate estimates. Just a lot of hard work. Still, here's a tip for free: anyone asking for a firm delivery date is inherently assuming BDUF. Once you know that, you know where to start your answer.

Tags: , , , , , , , ,

Management

scruffylookingcatherder.com

Information

    Recent Posts

    Calendar

    <<  September 2010  >>
    MoTuWeThFrSaSu
    303112345
    6789101112
    13141516171819
    20212223242526
    27282930123
    45678910

    View posts in large calendar
    Disclaimer
    The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

    © Copyright 2010 Scruffy-looking Cat Herder