Warfare As Software Development Metaphor

From: ArmCl

Regarding ArmCl, FrankStone asserts: The days of trench warfare are over. To survive on the modern battle field you must be quick and decisive. This isn't about talking and feeling good. You do not pull the trigger until words have failed.

Negative to that, soldier. Modern warfare is rarely quick nor decisive. Even massive military campaigns like Chechnya are long and leave many loose ends to be tied up. LeftWing warfare is even slower and totally indecisive by its very nature. When you take this analogy to software, you only call in a software team when no other solution is more cost effective. Otherwise, software teams will profiteer just like capitalistic military organizations.

Also, negative to pulling the trigger. Most modern campaigns aren't done under the auspices of warfare (no declaration of war). Once you pull the trigger, you must back up the decision to fire by international law. Thus, you have to prove your circumstances and your decision. Similarly with software; you have to be responsible for your decisions to the stakeholders. Talking about QualityWithoutaName isn't admissible in our legal system.

Under a declaration of war, also negative to your assertion that trench warfare is over. When ground troops are involved, trenches and fortified positions are still the most real part of the battle and where most of the war is fought. Consider the entrenched resistance in Grosny.

Also, during a declaration of war, it is irresponsible to not make maps of the terrain so other teams can avoid danger. It is irresponsible not to report information about your enemies' tactics and strategies so that soldiers coming after you can similarly avoid danger. Similarly, in software, you must "pass the torch" so that maintainers won't hit land mines of twisted code. CodeForTheMaintainer, soldier. That also means documenting project lore (and consequently, limiting lore).

From the TheArtOfWar, chapter 11. Information is the weapon. The more information you can get to yourself and your comrades, the more effective your side is during the campaign. Moreover, the more information you have, the more capable you are of defending the atrocities you perpetrated post-conflict. Ditto for software. Atrocities especially.

That is fine, ArmCl uses AfterActionDebrief?(s) to get the information to the decision makers, who write up the mission with the troops. The troops go out and do what they do. Mission are well defined, to add to the effectiveness of the AfterActionDebrief?.

I wonder what military you belonged to, Major, but mission objectives are really well-defined. They are rarely remotely defined in software. Mission objectives these days are "go stand there and protect the food." Or in the UsArmy?, "fly around until you can blow something up." Strategically, soldiers make no decisions, but tactically, they are responsible for all the actions. Similarly with software.

Besides, the only person capable of writing the documentation is the principle information holder. Secondary information holders already have an erronenous and incomplete comprehension of the mission. It's called a briefing because it's short. Actually, in software, the decision makers are totally unqualified to write a technical document.

: When you take this analogy to software, you only call in a software team when no other solution is more cost effective.

What are some business reasons that you would want to call in a software team when you already have a more cost effective solution? ( I am assuming that by cost you mean just hard currency? )