Path: utzoo!utgpu!bnr-vpa!bnr-fos!leibniz!schow From: schow@leibniz.uucp (Stanley Chow) Newsgroups: comp.software-eng Subject: Re: software engineers Message-ID: <493@bnr-fos.UUCP> Date: 10 May 89 04:05:06 GMT References: <4951@pt.cs.cmu.edu> <1736@internal.Apple.COM> Sender: news@bnr-fos.UUCP Reply-To: schow%BNR.CA.bitnet@relay.cs.net (Stanley Chow) Organization: Bell-Northern Research, Ottawa, Canada Lines: 79 Summary: Followup-To: Keywords: In article <1736@internal.Apple.COM> shebs@Apple.COM (Stanley Todd Shebs) writes: > >Comparing numbers of people or pounds of documentation is not necessarily >valid. My personal impression from working alongside assorted engineers >is that individuals tend to be more specialized in the traditional engineering >disciplines. [...] Perhaps this is why engineer build bridges that work better than most programs! There may be a lession for budding software engineers. > [...] So for instance you might have somebody on a project that is >concerned only with bolts, or electrical connectors, or maybe even with only >a single oddly-shaped part made by a subcontractor. Many (most?) software >people are in the opposite situation - they have to be concerned about all >aspects of a 50K line program, and they rarely have the leisure to really >understand the code proper, the design, the limitations, the consequences >for other parts of a system, and so forth. [...] I would consider 50K lines to be a (very) small part of a big software systen or project. (No smiley). If one person cannot totally comprehand a small program like that, either the person or the method ought to be examined carefully. As I understand "software engineering", a good part of the effort is devoted to making systems modular and understandable. One may disagree with the specific approach - Ada, Modula-2, C++, etc., but the aim is valid. 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". It would be nice if the mechanical engineer understood how stainless steel is made and what interesting reactions corode different steel, but it is not necessary to build a bridge. There are standards that gurantee N years of corodesion resistance as long as the exposure to corosive chemicals are within certain specific limits. The S/W analogy is like the mathmatics libraries. If you call this matrix inversion routine, you will get back a good inverse as long as the input matrix is not singular, etc. May be the answer is a mandotary course in "standard writing" for all software enginees. 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] > [...] Just imagine how different things >would be if you only had to be responsible for, say, 1,000 lines of code and >could spend a year working on it. You spend time analyzing it in depth, you >could polish the documentation, you could tune it for optimum performance. >Unfortunately such a situation is rarely possible in today's environment... > Aside from a quibble with your scale, I agree with your goal. However, I like to think that some, if not most, software projects are run better than you make it out to be. If the situation is indeed as bleak as you say, then I would worry about the future of S/W, especially in the USA or North America. >Getting back to comparing bridges and programs, a more valid method might be >to compare the information content of a program to that of a bridge (more >accurately, to the size of its description). This would factor out sheer >volume; 10,000 identical bolts aren't much more interesting than one bolt, >ditto for code that is replicated in different parts of a program. Seems >like at least one theorist would have looked at this in the past... > > stan shebs > shebs@apple.com This is a subject that has interested me over the years. Let's say I make a copy of a matrix addition routine, change it to do subtraction, how much information have I added? What metrics can we use? Is it possible to determine which programs are copies of each other? 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.