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.
jeffa@hpmwtd.HP.COM (Jeff Aguilera) (05/13/89)
> As someone said, "Software will be a science when programmers stand on each > other's shoulders instead of each other's toes." [I would be grateful if > someone can point to the originator of this] If I have seen farther than others, it is because I was standing on the shoulders of giants. -- Isaac Newton In the sciences, we are now uniquely privileged to sit side by side with the giants on whose shoulders we stand. -- Gerald Holton If I have not seen as far as others, it is because giants were standing on my shoulders. -- Hal Abelson In computer science, we stand on each other's feet. -- Brian K. Reid
weiner@novavax.UUCP (Bob Weiner) (05/19/89)
Stanley Chow (schow@BNR.CA) writes: > 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 is an egregious misstatement. I know many, many electrical engineers who also write software and though they spec their hardware one way, they do a horrible job on their software specs (if they ever even write a single word). Hence, it is not a problem with the mindset of software engineers, but more with the rest of the world, management in particular. They are the ones who let electricals focus on a very narrow area of expertise for more money than they pay software engineers that they expect to be able to solve any problem regardless of size, domain, complexity, etc., as long as it is deemed 'implementable' in software. Most real-world software engineering projects use many software engineers with little or no experience in the problem domain of the project. The software engineers know their base of knowledge well, but no amount of clamoring for 'domain experts' or 'close interaction with the customer' will change many manager's minds. Until software engineers are allowed to specialize as are their engineering brethren, the low quality and rampantly bad estimations associated with today's software projects will continue. One could also argue that software should not be viewed as a panacea for all of the system complexities that electrical engineers have trouble putting into reliable hardware. -- Bob Weiner, Motorola, Inc., USENET: ...!gatech!uflorida!novavax!weiner (407) 738-2087
mjl@cs.rit.edu (05/22/89)
In article <1275@novavax.UUCP> weiner@novavax.UUCP (Bob Weiner) writes: > >This is an egregious misstatement. I know many, many electrical >engineers who also write software and though they spec their hardware >one way, they do a horrible job on their software specs (if they ever >even write a single word). > Glad to see someone else noticed this. While not universal, it has been my experience that faced with a combined hardware/software problem, many engineers from the traditional disciplines are very professional in their approach to hardware, but then mutate into "key-bashing, get it out the door" software developers. Could it be that they use software development to release their pent up desires to hack around? As more than one such "engineer" has said to me: "after all, it's only software." Mike Lutz Rochester Institute of Technology Rochester, NY 14623 rutgers!rochester!ritcv!mjl Mike Lutz Rochester Institute of Technology, Rochester NY UUCP: {rutgers,cornell}!rochester!ritcv!mjl CSNET: mjl%rit@relay.cs.net INTERNET: mjl@cs.rit.edu
rwl@uvacs.cs.Virginia.EDU (Ray Lubinsky) (06/07/89)
In article <1122@cs.rit.edu>, mjl@cs.rit.edu writes: > As more than one such "engineer" has said to me: "after > all, it's only software." My usual retort when I hear this from computer hardware people is: Software without hardware is an idea. Hardware without software is a space heater. -- | Ray Lubinsky rwl@amber.cs.virginia.edu (Internet) | | rwl@virginia (BITnet) | | Department of Computer Science, ...!uunet!virginia!uvacs!rwl (UUCP) | | University of Virginia (804) 979-6188 (voice) |