I've fantasized about writing my own, but applying it to programming.

Several years back I had some discussions along these lines with a coworker who'd been in the Isaeli army. One of the sticking points we had was on the subject of collateral damage. In a military campaign, particularly in a "take that hill, dammit" action, you expect collateral damage as a matter of course, but it's most often someone else's problem to clean up. In software development, collateral damage is another source of defects; you might try to shove it out of the way (or define it away), but it still represents a pile of new defects, and you're unlikely to be able to avoid dealing with those defects for long without taking a reputation hit.

Dealing with collateral damage is where a number of approaches to reframing software development as X fall down. The level of precision, correctness, and robustness that software development requires is rarely understood or appreciated outside of our domain.