Tamir Nitzan tries to explain.

First, the word he mentions (pronounced “davka”) has a couple of different meanings, depending on context. But the slang meaning he refers to can loosely be translated to “in spite”. For example – “why won’t you let your little sister have the toy?” Answer: “davka” (embodying “I won’t give her the toy BECAUSE she wants it so much”).

As for the expressions (pronounced “rosh katan” – little head, vs. “rosh gadol” – big head). This expression comes from the IDF, and as most military language, doesn’t quite translate into normal language. A “rosh katan” (literally “little head”, and I actually think it is the original expression which derived most likely from “pinhead”, the contrast later came in as a complement) is someone that does exactly what he’s told. For instance, someone might be told to clean the barrel of their rifle. A “rosh katan” will strictly clean the barrel, perhaps leaving it useless because the trigger mechanism has sand in it, whereas a “rosh gadol” will clean the entire rifle and lubricate it so it’s ready for use and doesn’t rust. Another example: you tell a soldier to “go notify so-and-so that we will be ready for inspection at 1600”. By 1700 you’re curious, so you ask him “did you notify?”. His answer might be “well I called his office and left a message”. A “rosh gadol” would likely say: “I called his office but got his voice mail, so I left a message. I called back an hour later but still got voice mail, so I called his cell phone and left a message there too. I tried him again an hour after that and he assured me he will be here by 1600. I called him again 20 minutes ago and he said he was on his way but stuck in traffic” (a real “rosh gadol” would have notified his C.O. of all this without being asked of course).

Let me elaborate here… this is exactly right. Rosh katan is sometimes used in parts of the former British Commonwealth as labor action referred to as “work to rule.” For some reason you can’t go on strike, so you very carefully do your job exactly as prescribed, in a cussedly literal-minded way. “You told me to clean the toilet. You did not say to tell you when I was done. Therefore in accordance with your instructions I cleaned the toilet and stayed there in the toilet room waiting for further instructions.” Someone who is working to rule can always demonstrate that no matter how many orders you give someone, they can probably make themselves 100% useless while still obeying every order you give them. This passive-aggressive behavior is quite frowned upon in the Israeli army where the slang rosh katan (small head) describes it. However, it is often one of the only ways to resist authority in a system which is likely to penalize direct disobedience with swift and harsh penalties.

For example, if I assign a bug to a developer I expect them to:

1. reproduce the bug
2. if it’s not immediately reproducible, make a good faith effort to figure out why it’s happening to me instead of just assuming that I’m doped up on anti-allergy medication and hallucinating it
3. find the root cause
4. do some searches to see if the same errors were made elsewhere in the code
5. fix them all
6. test the fix
7. think about whether this bug might be causing serious implications for a customer who needs to be told about the fix
8. etc.

That’s the Rosh Gadol behavior. Possible Rosh Katan behaviors would be

1. resolved-not-repro. You can always get away with this once without even trying to repro the bug, because later you can pretend you didn’t understand the bug report.
2. without even reproing the bug, make a change to the source code that seems like it would fix it and resolve it as fixed. If it wasn’t, I’ll catch it when I close the bug, right? And if it’s really still broken, surely another tester will find it.

Rosh Gadol of course is quite the opposite: taking initiative and doing what is desired, not what is requested. Eric Sink alluded to it, in the difference between programmers and developers.

Back to Tamir.

Lastly there’s MSF. The author’s complaint about methodologies is that they essentially transform people into compliance monkeys. “our system isn’t working” — “but we signed all the phase exits!”. Intuitively, there is SOME truth in that. Any methodology that aims to promote consistency essentially has to cater to a lowest common denominator. The concept of a “repeatable process” implies that while all people are not the same, they can all produce the same way, and should all be monitored similarly. For instance, in software development, we like to have people unit-test their code. However, a good, experienced developer is about 100 times less likely to write bugs that will be uncovered during unit tests than a beginner. It is therefore practically useless for the former to write these… but most methodologies would enforce that he has to, or else you don’t pass some phase. At that point, he’s spending say 30% of his time on something essentially useless, which demotivates him. Since he isn’t motivated to develop aggressively, he’ll start giving large estimates, then not doing much, and perform his 9-5 duties to the letter. Project in crisis? Well, I did my unit tests. The rough translation of his sentence is: “methodologies encourage rock stars to become compliance monkeys, and I need everyone on my team to be a rock star”.

Exactly true. Daniel on the discussion group found a classic quote from Herman Wouk’s Caine Mutiny:

“The Navy is a master plan designed by geniuses for execution by idiots. If you’re not an idiot, but find yourself in the Navy, you can only operate well by pretending to be one. All the shortcuts and economies and common-sense changes that your native intelligence suggests to you are mistakes. Learn to quash them. Constantly ask yourself, ‘How would I do this if I were a fool?’ Throttle down your mind to a crawl. Then you’ll never go wrong.”

The trouble with MSF is that it starts with a group of successful developers, who are successful because they are resourceful, intelligent, experienced, well-meaning, and have plush private offices with doors that close, and then attempts to claim that if impose some of their “best practices” on your team of unskilled developers, you will achieve the same results. It’s like Daniel Boulud selling a manual to McDonald’s fry cooks. “Out of potatoes? Try Yams. Throw in a bit of rosemary. Toss and serve with a lime-basil aioli dipping sauce. Yum.” It’s just Best Practices, right?

I just ordered a copy of The Great Eskimo Vocabulary Hoax, which, among other things, debunks the stories about how Eskimos have lots of words for snow.

Now for the bit that only Hebrew speakers are going to understand.

No matter how debunked Whorf is, I’m still convinced that Israelis are more likely to do things דווקא, simply because they have a word for it. And I have been forced to write entire essays simply because I cannot find any other way to convey to English speakers the difference between ראש גדול and ראש קטן. All I wanted to say was that methodologies encourage ראש קטן and I need everyone on my team to be ראש גדול.

To someone who has never learned Hebrew it takes me two or three books to explain that. MSF is a fraud–an attempt to consolidate all the ראש גדול things Microsoft programmers do in a set of rules which are supposed to work if you force ראש קטן bizonim to implement them. And it’s never going to work.

I have been trying to translate this simple concept to English for years and am just about ready to give up. The Joel on Software award for excellence in technical translation will go to the person who can best express the preceding two paragraphs in English!

See that little picture of the books on the left hand side? It used to be 42,241 bytes long. 34,885 of those bytes were in a useless “application block” that some photo editing program put there. Thanks to Dennis Forbes, who posted an explanation and a free utility to remove the unneeded bloat, it’s now only 7354 bytes.

Interesting seminar. We had about 700 people in the audience. From my P.O.V., it was way too short — I could have talked about this social interface design for hours. And the Electric Cloud stuff was interesting enough but admittedly unrelated to my own topic which made the whole seminar kind of out of whack.