Friday, December 17, 2004

I'm just not evil enough

In the past couple of years I've been working hard to improve my capacity for evil, but it seems I'm not very good at it.

Now, before you get the wrong idea, I should probably clarify that I mean evil in the technical sense of the word, not the moral sense. To the hacker, that which does not support the highest potential of a thing is called evil. Thus, to run a business in a way that is less efficient, yet more profitable, is often considered evil by a hacker. In the hacker's way of thinking, it is evil to maximize profit at the expense of efficiency and good taste, if one could have those other things and still make some profit.

And yet, this view can be just as shortsighted as the view that looks only to profit. The hacker ethic of telling the truth, the whole truth, and nothing but, is often counter to the hacker's own ends. The hacker in me wants to tell people about the problems and the issues I see, as well as the solutions I already know and understand. The hacker in me wants to help people overcome the issues that face them now, and that I know will face them later.

But the politician in me knows that, with few exceptions, telling the truth doesn't actually work. If you don't see the problem, the solution I offer has no value. I've realized this intellectually for several years, ever since my presentation on the RIPP model (as implemented in ZPatterns) at a Python conference. I gave a well-attended talk, that left most people puzzled, but had half a dozen people raving afterwards about how important the RIPP solutions were. It wasn't actually until today, however, that I realized the real problem was not that people hadn't experienced the problems that caused Ty and I to develop RIPP.

No, the problem was, and is, much more subtle. People did and do experience the problems solved by the RIPP model, and the problems that are solved by many other advances in the state of the art since then. However, they do not always perceive them as problems! Instead, they tend to view architectural problems simply as unavoidable aspects of their work. (In much the same way, for example, as Java developers often overlook Pythonic ways of doing things, because they don't expect there to be easier ways than what they already know.)

Douglas Englebart, who led the development of the first word processor in the 1960's, tried to explain what word processing would be like to people who had never used a word processor. "Imagine a pencil," he would say. (I'm paraphrasing liberally here, by the way.) "Now imagine tying that pencil to a brick, so that to write you have to move not just the pencil, but the brick as well. That's actually what using your current tools is like. Now, imagine that you untie the brick. That's what using a word processor is like."

In essence, an astonishingly large number of developers are coding with bricks tied to their pencils. This is not, as I previously thought, because the developers in question lack smarts or an ability to get things done. Instead, I realized today, through conversations with some very bright, skilled developers, that the real issue is very simply that they never thought to look for a way to untie the brick, because to them, the unbelievable amounts of tedious, backbreaking labor they are doing is normal.

From my point of view, of course, their efforts verge on the insane and or suicidal -- and they would be for me personally. But that is not the case for them; it's just business as usual.

So, this creates a bit of a conflict for me. An ethical dilemna, to some extent. If I am honest about my perception of the extra effort they are "investing", I run the risk of appearing nitpicky, patronizing, or even insulting. I mean, if you tell somebody they have a brick tied to their pencil, they might feel stupid, no matter how hard you try to avoid implying that, and despite the fact that you don't actually think that they are.

Equally bad is the possibility that, once I've pointed out the brick, they may not believe it's really a brick, or that it really can be untied. They may think I'm making mountains out of molehills, or even refuse to acknowledge the brick because to do so would in their eyes be admitting that they overlooked the brick before.

But neither of these is the real ethical dilemna for me. The real dilemna is that I would be more likely to be able to help them, if I first lied to them! That is, if I first won their trust, and then gradually taught, politicked, and manipulated them over time to accomplish the results that would make things easier for them.

(Of course, by lied, I don't actually mean telling untruths. I mean simply, concealing my real opinions about things, and taking the effort to put positive spins on things instead of negative ones. This is not actually lying, but for someone as compulsively honest as I am, it feels like lying.)

Now, if I were actually making progress at being "evil", this should have been a snap for me. I could simply say all the right things to make them want to hire me, and keep my trap shut about "big picture" issues until after I was in a position to do something about them (or not).

And if I were actually able to be Evil with a capital E, I could probably rationalize not even trying to help them improve their process. After all, they would be so much more impressed when I worked miracles, then. And so what if their project doesn't work out? I'd still get paid, so why should I care?

But the fundamental "problem" is this: I do care. I frankly don't know how not to care. Trying not to care was one of the hardest things I ever had to do at Verio, and I sure as hell don't want to have to do it again.

On the other hand, if I commit to this project, and I do care, then it will be really hard to stop going around trying to get people to take the bricks off their pencils. Currently, in working on PEAK in a pure open-source mode, I don't have this as an issue because I don't depend on anybody else's output to achieve my goals. And, conversely, when I talk to people about architecture and design, it's in a context where they've already asked me for my input. That is, they've noticed that there is a brick on their pencil and believe I may be able to tell them how to untie it.

Tomorrow I'll be meeting with more of the team. I don't know yet if I will continue pointing out bricks, or simply switch to "sales mode" and convince them... No. I actually do know that I won't switch to sales mode. These people may not be my team now, but they will be later. My goal must not be, cannot be, to help them against their will. If what I have to offer isn't valued now, my actual contribution won't be valued later.

And, in a subtle irony, if I were to "dumb myself down" to be accepted, this is far more patronizing -- at least in my opinion -- than to try to offer a hand up. Because the offer of a hand up, means that I respect their abilities enough to believe that they can, and should, operate at my level. On the other hand, taking the sales tack would mean that I think that they're incapable of improving.

Alas, it's still not so cut-and-dried for me. One of the axioms of NLP is that "the meaning of a communication is the response you get". This is sort of a fancy way of saying that the best way to communicate something is the way that gets your point across, regardless of how you think you "should" communicate it. Unfortunately, there's no clear boundary between that concept, and the concept that the ends justify the means. Well-intentioned meddling is still meddling.

Ah, the heck with it. Whether they love me or hate me, I'm going to be who I am. If that works for them -- and they can tell that it works for them -- then great. The only hurdle left then, will be deciding whether they also work for me. And that's an even more complex question for me, than any of the other questions in this post. At least I've spent a lot more time thinking about the ethical questions!