News

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?

My new book is here! Apress has just published a new collection of 36 essays from Joel on Software, aptly named More Joel on Software. Get yours today! Available from Amazon.com or wherever fine cheese is sold.

About the Author: I’m your host, Joel Spolsky, a software developer in New York City. Since 2000, I've been writing about software development, management, business, and the Internet on this site. For my day job, I run Fog Creek Software, makers of FogBugz—the smart bug tracking software with the stupid name, and Fog Creek Copilot—the easiest way to provide remote tech support over the Internet, with nothing to install or configure.

Enter your email address to receive a (very occasional) email whenever I write a major new article. You can unsubscribe at any time, of course.