Older blog entries for apenwarr (starting at number 72)

20 Oct 2005 (updated 30 Oct 2005 at 19:31 UTC) »
Disturbing News

I got back to Montreal tonight and flipped on the TV. The local CTV news was just starting. One of their only two headline stories:

"Parents are demanding that the city place a crossing guard outside an elementary school... (dramatic pause) and it seems the government is listening."

Yikes! We need crossing guards now? Outside of our elementary schools? And the government is listening? What is this country coming to?

English Grammar is Almost As Dense as Perl

There, no kitchen is an island.

There is no kitchen island.

There is Kitchen! No! Island!

There is no island, Kitchen.

There is Kitchen Island, no?

No! There is Island Kitchen!

Kitchen is there. Island, no.

Is there Island Kitchen? No? Is Island Kitchen -- no, there! Island Kitchen is there, no?

...

So please don't ask me why compilers never auto-correct your punctuation.

6 Oct 2005 (updated 6 Oct 2005 at 01:33 UTC) »
Super Powers

adewhurst, I think you'd find that clairvoyance would get you a lot further than telekinesis, if you used it the right way. You don't really need both.

Cryptic Insight

Focus.

27 Sep 2005 (updated 5 Oct 2005 at 22:12 UTC) »
No wonder things didn't make any sense!

UI design isn't specification, it's design. You'd think I would have guessed from the name.

That makes a big difference in how you should approach it.

Backdate (2005/10/05): Not really an update, but it appears I was thinking of this same stuff about a year ago, without coming to an answer. Spooky.

Membership Control and Groupthink

sfllaw expands nicely on the topics I brought up in my previous entries, but agrees with me a bit more than I'd like, so I'll have to resort to arguing with myself. That, incidentally, is exactly the crux of what I'm about to explain.

In one class in first year Engineering, Professor Aplevich mentioned in passing an effect called Groupthink. It's really important, and it stuck with me.

Imagine you take a group of four people, and you give them the basic outline of a project. Isolate the group from co-workers, other groups, and especially customers. It doesn't matter much whether the members initially agree or not, as long as their personalities don't totally clash. Make them work together on their project - four people on a single project can be a very tight team - for a few weeks or months. Now, let them out of their cells, er, cubicles and see what they've accomplished. Two things are almost universally likely:

- Despite any number of initially differing opinions, the group is almost always in final agreement about the way they executed their project.

- The mutually agreed-upon project is usually complete garbage because the group has lost all perspective of reality. Trying to convince the team members of this, however, can be extremely difficult.

It all makes sense, of course: over time, all the objections that four people can think of will be addressed, and they'll eventually come up with a mutually satisfactory "point solution" - one that deals with all the problems any of them can think of. But there are lots of solutions that fit that small number of points. Unfortunately, reality contains many more points, and the solution that a small, isolated group will come up with is almost always incompatible with reality. In fact, a solution that all four members wouldn't agree to, but which agreed more closely with reality, would be a much better solution.

Now think about the mechanics of Membership Control: how can it not lead to Groupthink? Strictly controlled group membership is effectively self-imposed thought isolation; members of the group aren't exposed to reality, because they deliberately block out the aspects of reality they don't like. We're free software developers; we don't talk to those Proprietary Weenies. We're techies; we don't talk to those Business Weenies. And so on.

The result is exactly the result you get from Groupthink: a bunch of people who can work together towards a common goal and produce a self-consistent solution that fails completely in the real world, because the real world is larger than the group's sphere of understanding. Free software misses problems that are obvious to people making proprietary software, and vice versa. Brilliantly cool stuff designed by isolated techies can't sell, and ideas proposed by marketing are unimplementable.

You can surround yourself with people who agree with you - not just because they're Yes Men, but because they really really believe in the same things you really really believe in. In fact, the Internet guarantees that, no matter who you are, you can find such people. But it doesn't mean you're right.

Membership Control always leads to Groupthink. If you are right, this is amazingly efficient. But chances are you're not. If you're not, who will tell you so?

sfllaw seems to have gotten interested in my last entry, and I'm trying to procrastinate right now, so I guess I'll fill in my next segment a bit sooner than I planned. Read Simon's analysis here.

(Quick response: Simon says many correct things, but I think he suffers from a bias towards ignoring the Exclusivity rule. Most Open Source-type people do, and the failings of Open Source compared to commercial software - and yes, there are some - can largely be explained by this.)

The Meaning of Power

The trick here is not to disprove one of the four rules, which should be difficult; each rule is pretty self-contained and almost "inherently obvious." The trick is to find a way to obey all four rules at the same time. To do that, you have to realize that one or more hidden assumptions - what you used to make decisions for action based on the rules - was wrong.

I'm sure there are lots of "premises" - fundamental assumptions - you can reject in my earlier analysis. That seems to be the way life works. Here's the one that fascinates me the most: the meaning of power.

Power over people comes in many forms. The simplest form is physical coercion; if I push you over a cliff, you're just plain going to fall off the cliff, and all the Quantization rules in the world aren't going to save you. However, this is virtually worthless for getting intellectual work done. You can force someone not to think, but you can't force them to think.

Another kind of power is a bit closer, and many organizations (especially military, and other highly hierarchical organizations) use this as their defining structure: the threat of coercion. There are consequences if you disobey - sometimes even death. So you obey. By doing this, you're "taking responsibility" for the consequences of your actions, ie. Not Getting Punished, so you're in compliance with the four rules. But now you're getting into my earlier comments about dueling stupidities in Company Policy.

There are other kinds of power as well, which are much more subtle but which I think can work much better. Here is one, which Simon also alluded to in his response earlier.

The Power to Control Membership

Also known as "hiring and firing." Here's how it works: if someone agrees with what you're doing, you hire them. If they disagree, you fire them. Repeat this process enough times (people's opinions change over time, of course, and so do yours) and you eventually converge on a group whose interests are aligned. There's no longer any reason why the person with primary responsibility will have to worry about disobedience from the others; the others have a natural tendency to want to do exactly those things that he wants them to do.

Note that this method is different from the threat of firing: that's just the threat of coercion again. There is no fear involved (strictly speaking) in the Membership Control method.

I think people underestimate how much Membership Control is at the root of the problems/successes with most organizational behaviour, because it sounds like such a blunt tool. Firing people just because they don't think the right way? Ouch!

But you do it anyway. When you voluntarily leave a group, you do it to yourself. How about these examples:

  • People who use HTML-only mail get ignored on technical mailing lists.
  • The Apache Core team is selected based on how well the candidates' interests align with the interests of the existing core team.
  • Debian won't let new members in unless they agree to the DFSG (and nowadays, possibly other rules). Conversely: there are no Debian developers that are violently opposed to Free Software, even though such people (often very smart ones) exist.
  • The most successful companies attract the best job candidates.
  • People who really love video games and are willing to work long hours (everyone knows game developers work long hours!) apply to video game companies.
  • "Techies" don't really like "suits", and vice versa. Every company has its place along that continuum, and you won't work there if you can't handle the particular environment.

You can talk about charismatic leaders, information sharing, and natural consensus, and there's plenty of truth to it, of course. But in real life, organizations often stick together simply because the members self-select themselves for compatibility with the goals of the group. Once you have that, your charismatic leader has a much easier job.

More Logical Inconsistency

Here's another fun example related to organizational behaviour. First, the rule that makes cooperation worthwhile in the first place:

1. Limited Energy: some problems are too big to be solved by a single person working alone.

Another important rule that I've proven empirically by violating it (and observing numerous other violations that weren't my fault) implies that you need to have clear divisions of responsibility:

2. Exclusivity: only one person can take responsibility for any particular thing. If the responsibility for something is divided between two people (or worse, a committee!), then when a difficult issue comes up, each person will hope someone else will deal with it, which means nobody does. The only times this doesn't happen are when one of the members does feel personally responsible and manages to override the other more apathetic committee members - but that's just a messy version of having no committee at all.

Applying the Exclusivity and Limited Energy rules quickly leads us to discover another rule that implies the need for hierarchy:

3. Balance of Power: In the words of spider-man's uncle, "With great power comes responsibility." And vice versa. You can't be held responsible for something unless you have the power to affect it. If you have the power to affect something, then you're responsible for its outcome, because you're the one who controls the outcome; that's what power means.

If we work together to solve large problems (Limited Energy), and only one person can be responsible for a particular outcome (Exclusivity), and the person responsible for an outcome has to have power to control that outcome (Balance), then a logical conclusion is this: for any large problem, a single person must have final responsibility to tell other people on the project what to do, and the power to enforce his decision.

All this is pretty widely accepted and has been the way things have worked for probably hundreds or thousands of years. Unfortunately, there is a fourth rule:

4. Quantization: the smallest amount of power a person can have is power over his own actions. He may deny his responsibility; he may subjugate it to someone in a higher position of authority; but he simply can't give up the power over his own actions. And so by the Balance rule, the responsibility is still his.

This messes up our nice, clean system. Quantization says you can't give someone power over someone else's actions. Balance says you can't give someone responsibility for someone else's actions if you can't give them the power too. Exclusivity says, in that case, that your manager has no power at all. The reason we wanted him to have power was because Limited Energy says he can't do it all himself, and Exclusivity says only a single person must be held responsible for the overall result.

I think nearly all organizational structures violate at least one of the four rules. Hierarchies violate Quantization, or Balance, or both; collective/consensus structures violate Exclusivity; pure individualism (libertarians?) violate Limited Energy.

But I believe all four rules are correct and necessary; every violation leads to predictable failure.

Check your premises.

7 Sep 2005 (updated 7 Sep 2005 at 04:33 UTC) »
Logical Inconsistency

I'm learning a lot of things in the last little while. Here's a fun set of facts:

1. The more customers you have, the more problems they'll find. Feature request lists grow boundlessly, and you'll never finish them all. Accept imperfection, and aim to solve the most important problems first.

2. Nobody will use your product unless you eliminate 100% of their reasons not to use it. Since solving 90% of problems is not the same as solving 100% of the problems for 90% of people, a partial solution isn't acceptable. Aim for perfection.

(Doesn't this sound like the two sides of the argument in Worse is Better?)

Think of those two points by themselves; you can probably agree with each one. Each one suggests a course of action to respond to the problem. But put together, no solution seems to make sense: nobody will use your product until you finish going through the entire requirements list, but the list of things people ask for will expand endlessly. The only sensible course of action suggested by each one is nullified by the problem suggested by the other.

I realize it's generally social suicide to quote Ayn Rand, lest you be labeled a crackpot, but sometimes she said smart things:

Contradictions do not exist. Whenever you think you are facing a contradiction, check your premises. You will find that one of them is wrong.
-- Ayn Rand, Atlas Shrugged

The wrong premise in this case? Maybe it's obvious to you now, but it wasn't obvious to me. To solve the problem, you need to redefine the problem itself. One way is to find an important subset of people, then solve all their problems. In other words, you have to find a way to solve both #1 and #2 at once.

Contradictions do not exist. It's good advice. When you have a contradiction, you can't possibly succeed until you figure out what it is, because the real solution is neither of the obvious ones.

There Is Another Zone

I've discovered that it's actually possible to geek out on marketing.

Programmers know that programming efficiency comes largely from getting into The Zone for a few consecutive hours - and those few hours can be 5x-10x as productive as "normal" working hours.

Well, for a change of scenery (and because it was necessary to get my job done), I relocated myself temporarily from Montreal to our Toronto office for the last few weeks. This place is not an environment conducive to getting into The Zone in any normal sense. It's not an R&D department. It's a business environment, where people have daily problems, and those problems all seem important, and they really want to solve those problems right now.

Luckily, my job in the last few weeks has mostly not been programming; it's been doing a bunch of random business supporting tasks for a new product we're working on, where the product largely consists of repackaging our existing technology into a newer, more "customer focussed" package. To do that, I had to learn a bit about marketing, a bit about customer business models, a bit about project management, a bit about salespeople, a bit about financial projection, a bit about technical support, a bit about manufacturing, a bit about "webinars", a rather scary amount about IBM DB2, and lots of other things. Then, in real time, I had to turn around this new knowledge and apply it to my work. And I had to do all that in a very short time.

So I dedicated every waking moment to learning and doing that stuff. When I wasn't working, I was reading books about it. When I wasn't doing that, I was eating while thinking about it. When I wasn't doing that, I was dreaming about it, and sometimes I would wake up with the right answer.

Whether I did a good job or not in the end isn't really the point, but the process itself is really interesting: you can deliberately focus your thought processes on a specific set of complex, confusing, interrelated things, and tune out everything else. When you do, you're doing something very similar to programming in The Zone. The magic in programming happens because when you hold all the concepts in your head at once, you can just see the answer clearly; the right answer is the only thing that fits all the pieces at the same time. It turns out that other kinds of work can be done the same way.

The result is that I know and understand a lot more things than I did a month ago. I understand a few things that even the people teaching me didn't understand, because they weren't in The Zone at the time: they didn't see the whole picture.

The problem is, once you've seen the big picture, you'll never not see the big picture. It's very hard to go back and sit in your pigeonhole.

The true hero - the truly good person - is the believer who risks an eternity in hell by refusing an unjust demand by God.

-- Alan Dershowitz

63 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!