11 October 04 - 19:03Reclaiming groupthink

Recently, I've caught myself musing that "groupthink" has an undeserved reputation. The term has come to mean "suppression, within a group, of voices dissenting with an incorrect or suspect decision".

That isn't a specialty of groups. A supposedly "integrated" personality is quite capable of being, so to speak, of two minds about a given decision, yet suppressing its misgivings and pressing on.

I'm fond of the term "escalation", which in this paper is defined as "increasing commitment to a failing course of action". If we can find terms which are perfectly appropriate for the same dysfunction in both groups and individuals, why does "groupthink" enjoy such popularity ?

I think the main reason is that we don't want to believe that a single mind is capable of (what we ought to call) "groupthink". We want to believe that, as individuals, we have rational or moral reasons for suppressing internal dissent; for instance, we speak of listening to our head instead of our heart, or the reverse.

Rather than recognize the dissent for what it is - an internal debate deserving, as it does in groups, a resolution from due process rather than by fiat - we prefer to invoke absolute judgements on abstractions: "emotions are not rational", or "logic is soulless". We're evading the truth: we are large, we contain multitudes.

Conversely, a group which has achieved a high degree of integration - which we may want to call a "team" - is not necessarily a bad thing.

- Private Life Of The Brain - one comment / No trackbacks - § ¶

10 October 04 - 21:59The "best" code

Spurred by programmers' reactions to a refactoring exercise in a class he teaches, in which people seem to prefer leaving some duplication in the code because it appears to communicate intent better, Ron Jeffries asked:

What is the "best" code? Is it the code with minimal number of symbols or minimal number of statements or opcodes? Or is it the code that will communicate best with the reader?

This sort of problem crops up time and again in Douglas Hofstadter's book on translation, Le Ton Beau De Marot, and he makes a good case that it is a fundamental feature of what it is to express ideas.

When trying to translate an English term, say "breakfast", to French, you might hit on "déjeuner". This doesn't quite work, though, because as a noun you would say "le petit déjeuner". "Petit" means "little", we call the first meal of the day "small" because the midday meal is called "déjeuner", and we typically eat more.

"Breakfast" and "déjeuner" are almost literal translations of each other - the latter would literally translate as "un-fast". It's really too bad that you have to use two words to translate one, especially when the one word actually means, etymologically speaking, what you end up having to say with two. Argh !

Coding raises the same kind of uneasy tension between semantic issues and formal ones. This bit of code has meaning closer to what we want to say, except that it has duplication.

There's something like "grain size" involved in this. For instance, if you're translating the single word "breakfast" then you're stuck - you can't preserve both meaning and word count. But if you're translating a larger fragment, a sentence or a paragraph, it's much easier to get a translation that globally preserve word count (if for some reason you're trying to do that). There are ways to rearrange meaning around so that you end up in the right place.

I'm guessing that code is just like this, too - there are choices you need to make at a very small grain that leave no possibility of getting the "best" code in an absolute sense. "Best" is a point in abstract space but cannot be realized "physically" due to the grain size of code - a lot like drawing lines or circles at low-resolution, you can smooth out jaggies but not avoid them entirely, and at ultra- low resolutions the best algorithms will break down eventually.

Yet we can still recognize that abstract "best" and aim for getting ever closer to it in our imperfect realizations.

- Software Development - four comments / No trackbacks - § ¶

09 October 04 - 23:33Managing musicians

Keith Ray striking a funny note:

Can you imagine a group of people composing music in an hierarchical chain of command: a chief composer, with middle-manager-composers, and squads of junior composers?

Reports of actual team composing are rare, and less funny, but quite interesting. The second link has a description reminiscent of Keith's, with a "music director" overseeing composition, in parallel by "grunt" composers, of successive temporal chunks. This was the kicker for me: "It was the Music Director who actually received screen credit for the music."

Some things are the same everywhere.

- default - one comment / No trackbacks - § ¶

09 October 04 - 23:12It's the reviewing, not the reviews

I've been reading a thread on a Java forum, about a hapless engineer who had been "assigned code to review it for performance issues". The story was fascinating - wrong in so many different ways. To name but the top two, making "review" an individual assignment, and skimping on the money to buy the natural tool for performance issues - a profiler.

This hints to blind belief in the effectiveness of "code reviews". I'm reminded of Eisenhower's quip, "Plans are useless, planning is indispensable". Reviews are useless, but reviewing is indispensable. That is, what makes reviews work is not the form by itself - the fact of having a meeting (or asking one person) to examine code, designs, or other artefacts. The benefits of reviews come from an understanding of the results that are expected, and matching the form to the results.

In the thread, the engineer (I'll call him Seth - not his real name) was explaining that the system had just gone live and the users were complaining about performance. Just like testing, reviews coming this late in a development effort are useless. Reviews can't "add performance" or "add quality" to code that didn't have it to start with. What they can do is provide an early warning system for quality or performance issues.

Seth started out with a checklist provided by his management - look for uses of String rather than StringBuffer, unnecessary logging, etc. That didn't help him much. Then he spent some time working with some of his developer colleagues, asking each of them to review one method with him. He came out of that with a much larger palette of "efficiency tricks". This is a key reason why reviews are typically conducted as meetings, or at least by pairs of programmers as in XP. The idea is that many brains are better than one.

In the end, Seth realized he would probably get nowhere. One reason was that he knew he wasn't adressing the real problems, only getting nickel-and-dime efficiency savings. It really takes a profiler to find the kind of potential optimizations that will make a difference, the 10% of the functionality where 90% of the time is wasted. Worse, it looked as if the problem really was with an underpowered infrastructure. Reviews should have realistic and achievable objectives, other than to salve guilty consciences.

There was a more subtle reason Seth decided he was getting nowhere. After a while the users' complaints started to focus on bugs, and all of a sudden performance wasn't an issue anymore, Seth's recommendations filed, unread, in his manager's inbox. As I said, reviews are beneficial only if you understand what results to expect from them, and chif among these results is establishing an atmosphere of accountability, visibility and "reviewability" of a knowledge team's work products. If you go looking for problems, you must be prepared to actually do something about these problems.

In addition, "reviewability" should also be a feature of the projects's process... and of its management.

- Software Development - two comments / No trackbacks - § ¶

08 October 04 - 18:33Thinking in tests

"How", they say, "can you suggest that 'test' is literally the first thing in your development cycle ? Surely you can't write a test before having at the very least done a minimum of analysis, preferably on paper, to pin down what the interfaces are, the method names and what they're supposed to do and their parameter types and return types..."

Doing your analysis "on paper" amounts to jotting down thoughts. These are probably in somewhat symbolic form - squares, arrows, and so on. But you could just as well do it in English, I suppose.

Imagine you were learning French(*), and for the fun of it decided to write down your analysis thoughts in French. At first the process would be quite laborious - you'd have to formulate your thoughts in English to get them into a coherent state, then translate to French. After a while, though, as you grew proficient in French, you would directly put down your thoughts in French. (I know I'm painting a rosy picture - past a certain age one's brain is no longer plastic enough to learn to think in a new language, so it might take forever to get to that level of proficiency - but that's an implementation detail; just hold the rosy thought till I get to the next step.)

Now, in the above, imagine replacing "French" with "tests". A programmer who has been addicted to test-first for long enough is doing analysis in the language of tests. Her thoughts run "I want to assert this, which should follow from that, if I have this and that object set up with that data", but their function is the same as your quick jottings on paper... except that they will morph into an executable test seamlessly.

(*) If, like me, you are a non-native English speaker, substitute your native language for "English" and a language you don't know for "French".

- Extreme Programming - one comment / No trackbacks - § ¶

07 October 04 - 12:47Responsibility and Priority

"When everything is a priority, nothing is a priority." This may look like common sense, but let's be cautious about aphorisms, their seductive symmetry and catchiness.

What the aphorism suggests about the nature of priority is that it's relative. Imagine that your team represents higher priority tasks with lower numbers. You know that number 42 needs to be done before number 47. And it's all that matters - the numbers could be 142 and 147, that would make no difference. But they can't all be 42 - if they were, the priorities would be useless for determining what to do first.

So the aphorism tells us something useful. But... not everything is relative. For the same work, you would prefer to earn $142 than only $42.

What about "If everyone is responsible, then no-one is responsible" ? That also sounds like common sense. But sounding good doesn't make it true, or useful. That would only be the case if responsiblity (in some sense) is just like priority, completely relative - if we didn't care how much someone is responsible - we just care who is more responsible.

What's a responsible person ? One who is willing to live with the consequences of her decisions. That's not something I would want to evaluate on a relative basis. I do care how much responsibility I can expect from someone - how many of her promises she's likely to keep, or take appropriate steps if she breaks them.

How useful is the "no-one responsible" aphorism ? Not much. It's just memorable.

- Management - two comments / No trackbacks - § ¶