August 8th, 2006
Joel Spolsky has another lovely article out titled, “The Command and Control Management Method“. While he hits the nail on the head for most of the article, I feel he misses one of the main reasons while C&C management does not work for software development teams.
Actually, he misses one of the main reasons the C&C pattern doesn’t even work for the military.
It all begins with the 1973 (no, seriously) Yom Kipur War between Israel, Egypt and Syria. Having taken Israel by surprise, the Syrian tank divisions storm through the Golan Heights and almost reach Nafah where the headquarters for the Israeli forces were located.
Had the Syrian forces reached Nafah, they would have most likely defeated Israel and conquered the Golan Heights at the very least. But they haven’t, and didn’t — instead, they stopped.
Just before overtaking Nafah (‘on Nafah’s fences’ as Wikipedia describes it), the Syrians halted their advance. This allowed time for Israeli reserve forces to arrive en-mass and overturn the tides of war, eventually costing the Syrians their victory. To this day, no one outside Syria (and maybe Israeli Intelligence) knows for certain why the Syrian force stopped so abruptly.
There is a prevailing theory, however. This theory boils down to the difference in management style between Arab armies (Soviet trained) and the IDF. Arab armies are trained for complete Command and Control management, an underling will not make a move without being issued a command. The most initiative he can show is to suggest a course of action to his superior, who might suggest it to his and so forth until the highest authority on the matter is reached, once he makes a decision the order to action travels down the chain of command. As any software engineer will tell you, this upstream-downstream transaction means very high latency.
Israeli military on the other hand, have an altogether different standing order: a soldier without immediate contact to his supervisor is his own chief-of-staff. This translates to initiative and rapid response during the fog of war.
So imagine that the Syrian tank brigade commander, having surpassed his superiors’ expectations and advanced so quickly into Israeli held territory that he exhausted his current orders. He was not meant to reach Nafah so quickly! As he is trained not to question his orders, and as he is only given very limited information (on a supposed ‘need to know basis’) he can’t assume that proceeding forward would fit with the larger plan.
Thus our well trained commander jubilantly radios back his headquarters and informs them of his brilliant success and requests further instructions. While his report travels up the command vine, he and his forces are minutes away from victory and are standing completely still.
The next step of the reasoning is quite clear:
Use a command and control management style and you will be the bottleneck of every development step, as every decision beyond what to call the class file will be relegated to you. This is not just hit-and-run micromanagement, this is a semaphore locked development cycle and is hardly an efficient use of your very valuable resources (otherwise known as: people).
While there are many (many!) number of arguments why C&C does NOT work for software development projects (for example: writing good software is a creative process, C&C management hampers creativity) I think the above is the most important and most direct argument against such a style of management.
Having said that, there are places where C&C is just fine.