schow@leibniz.uucp (Stanley Chow) (05/11/89)
Since we are starting to talk about components, I have added comp.sw.components. In article <1764@internal.Apple.COM> shebs@Apple.COM (Stanley Todd Shebs) writes: >In article <493@bnr-fos.UUCP> schow%BNR.CA.bitnet@relay.cs.net (Stanley Chow) writes: > >>In big systems, even in small 50KLOC programs, it is important to partition the >>program into understandable chunks. S/W people call this module interface. The >>civil/mechanical engineers call this "specification". > >Only amateur programmers and researchers work without specifications these >days. The issues revolve around how formal the specifications can be. >Informal specifications seem to cause as much difficulty as they resolve, >while formal specifications are fantastically hard to get right. > >>May be the answer is a mandotary course in "standard writing" for all >>software enginees. > >Undergraduate software engineering classes feature the writing of interface >specs, but the environment is too artificial to get students to feel a >realistic level of pain at having to conform to a bad specification. >Classes can't always substitute for experience... > What I had in mind is the amount of details in the specification. Most standards written by traditional engineers, be it mechanical, electrical or whatever, tend to be a good deal more detailed than software specs. May be the Mil. Spec. methods of software development are better but I doubt it. The only really complete documentation I have seen are IBM manuals. They are long and boring, but they are *complete*. Modularity and software reuse requires a very high level of documentation. An example is the simple IC. A couple of articles in comp.sw.components recently talked about "software IC". Consider the simplest of IC's, say a 5400 -- quad nand-gate. The documentation goes for several pages: - logic function table, - the standard logic symbol, - the boolean equation, - pinout information for each possible package, - the equivalent schematics, - the absolute maximum ratings (complete with ambient conditions), - the recommanded operating conditions (with min, max & nominal) - complete characterization (with conditions, min, max, ..) Note that the concept of a "nand gate" is captured and encapsulated. It just requires a lot of details to describe the encapsulated module! With this level of information, I can design an IC into a circuit and know what it is doing, what is the operating envelope, and complain to the manufacturer if the IC does not meet spec. Most (if not all) hardware type know just about all of this information since a lot of it is standard across parts in the same family and across families. The information is repeated anyway becuase it is part of the specification. How many times have you seen *any* software documentation that comes close to this level of information? Some people may say, but the hardware guys are selling IC into a commodity market so they *have* to characterize their parts. This is true to a certain extent. But the companies that sell, say, compilers, would seems to fit that description as well, but have you seen a compiler (or even "make") described in detail? Other people may say, but software is more complex. Firstly, there are some really complicated hardware, take a look at some of the monster chips. Even very complicated hardware is documented in detail. Secondly, there are some very simple software. Even very simple software is not well documented. It appears to me to be a matter of expectation. Hardware types won't even think about using a part unless the specs are there. Software types don't care. This may have something to do with specialization: there are IC vs PCB designers, analog vs digital designers, micro-wave vs RF designers, etc. Many software people seem to think they can do it all (this probably applies to me as well, but in my case, i *can* do everything! :-). Another aspect is knowledge. Hardware people have been burnt enough times that they put the knowledge into specifications. Software people are still arguing about what are problems, what is good and what is bad. Hmm, this is getting pretty long. I better stop rambling before everyone thinks I am bashing software or s/w engineering. Stanley Chow BitNet: schow@BNR.CA BNR UUCP: ..!psuvax1!BNR.CA.bitnet!schow (613) 763-2831 ..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public I am just a small cog in a big machine. I don't represent nobody.