Errrm, you are right so long as nothing changes. As soon as anything changes the merrily chugging COBOL becomes a weird frizzie step aunt from an obscure island near Antarctica and, well, stops the chugging and starts jitterbugging.
Then everyone does a "what the hell is going on" dance and wheels barrows full of cash into a carpark where "consultants" pour lighter fluid onto them and burn bonuses in a horrifying money sacrifice to the dark gods of bug fixing.
After awhile everything returns to normal.
Where did you hear the thing about fault tolerance from? Is there a seat at that bar for me?
It's just a property of the artifact you're building. You're designing a process instead of a product. The artifact you produce is a description of that process--code.
The closet thing I can think of is anyone who works on processes instead of products. If you look at disciplines that design processes, the larger the scope of the process, the less exact the methods to design them (mainly because the number of variables grows too large).
At one end, industrial engineers who design assembly lines have very rigorous design methodologies backed by math and empirical data. At the other extreme you have politicians designing the process of running a country, and their methodologies are almost never based on math or empirical evidence.
One way I've heard it described is kind of midway between an industrial engineer and a politician--When designing a large scale software system, you should be like an urban planner. You decide what kind of zoning you need--residential over here, commercial over there. Then you build the roads and other infrastructure that connects the various districts.
I agree with your analogies, but I think that there are at least a few intermediate levels between high-level process description and code that benefit from some sort of spec. Good specs fill the gaps between the zoning and the pavement.
There is no ASCII representation of a bridge which is actually a bridge. Other engineering disciplines are in the business of producing matter with certain properties; the description of the properties is fundamentally distinct from the matter itself.
There is an ASCII representation of every piece of software which is actually that software: its source code.
This would also explain why "code as spec" goes hand in hand with modern, expressive languages: a sufficiently large C program is not human-readable as a description of its own behavior. If you want to create the program you intend to create, it is necessary to write a specification at a higher level of abstraction, then hand-translate that into C, and attempt to keep the two in sync.
Whereas one can read/write business logic in Ruby, Python, or whatever about as well as they can read/write a description of the same logic in English.
A sufficiently large program in [any language] is not readable as a description of its own behavior. I think it's easy to fall into the trap of thinking this is not true for expressive languages like Ruby or Python, because there are precious few projects of sufficient complexity written in those languages.
If you think I'm wrong, please show me the Ruby equivalent of an os kernel or Photoshop, and I'll reevaluate my thinking.
More importantly, every program can be seen as, at some level, a description of its own behavior. But none contain a description of the system's intent.