The problem with software is that the software is the specification. Any sufficiently detailed software spec will need to be written in a formal language that might as well be code.
I know that's received wisdom in some parts, but is it actually true? Is it true for other engineering disciplines? Is it true for hardware design? If not, what makes software special?
I think it only seems true because of the amount of money people are willing to invest in software development, relative to other ventures.
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.
