Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!mips!prls!pyramid!athertn!hemlock!mcgregor From: mcgregor@hemlock.Atherton.COM (Scott McGregor) Newsgroups: comp.software-eng Subject: Re: Development vs Engineering Message-ID: <32174@athertn.Atherton.COM> Date: 17 Oct 90 17:29:57 GMT References: <32087@athertn.Atherton.COM> <32084@athertn.Atherton.COM> <27696@bellcore.bellcore.com> <2450009@hpfcmgw.HP.COM> <84754@tut.cis.ohio-state.edu> <5682@stpstn.UUCP> <320 Sender: news@athertn.Atherton.COM Reply-To: mcgregor@hemlock.Atherton.COM (Scott McGregor) Distribution: comp Organization: Atherton Technology -- Sunnyvale, CA Lines: 89 In article , cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: > Wellll, I get the point (and have seen it *a lot* around here), but, with > respect to object-orientation, it would seem that copied code is not the > > form of reusable code we want to achieve. Probably not. However, I bring it up because I believe that the major forces affecting reuse behavior are sociological and psychological, and not technological. People like reusing their own code because they have faith in their previous efforts, and because they can use easy ASSOCIATIVE memory ways of finding it. They like copying code from an editor because they don't have to think deeply about writing generalized code the first time, it can be easily and incrementally modified to the task at hand, and because copying and pasting is a daily reinforced activity in most editing tasks (including non-coding tasks). When uncertain, the code can also be examined directly to give one a sense of confidence. Laziness plays a certain part in the copying decision, but so does enjoyment in coding (discovering) a new algorithm which might overwhelm laziness whenever a fit is uncertain. I believe that another related form of copying is use of standard subroutine libraries (e.g. libc, libBSD, Xtk, etc.) Here, the user has less certainty about the implementation, and in fact it is common to see people who have implemented their own memory allocation, sort or string routines because they thought they could do better than the standard ones, because they were unaware of a standard subroutine's existance, or because they wanted their own custom interface. But for another set of programmers these subroutines are merely treated as extended primitives in the programming language they use. Brad Cox has noted the similarity between code module/object reuse and interchangable components in firearms. One of the interesting thing to note about that is that most of the components are visible to the user who, if a knowledgable gunsmith, can visually determine their quality. The packaging for most subroutine libraries and object libraries is not their viewable code form, but a compiled form, requiring considerable more effort for an expert to judge quality and suitability from. On the other hand, for non-experts this is irrelevant. They like the fact that they DON'T HAVE TO BE EXPERT, but can make decisions on marketing glossies alone and the have greater faith in the expertise of the producer than they have in their own abilities. I believe that Brad has noted gunsmith opposition to interchangable parts when introduced, but that it was the soldiers in the field and other consumers who preferred them. This leads to a sociological observation, namely that one will see object-level reuse begin with the nonexperts first (accountants who purchase a shrink-wrapped accounting package, not a programmer). And then you will probably see acceptance by the fringe programmers (4GL users, Lotus macro writers et. al who don't think they are programmers), and then applications programmers (who will use a library of "standards" such as Xtk...) In other words, object style reuse is most desirable to those who have no interest in doing the work in the first place! It should not be surprising to see that in fact shrink-wrap software, 4GL and other non-procedural applications use is up but we often don't count that as object reuse. Object oriented libraries aimed at "professional programmers" are facing a more difficult battle. A related problem in the acceptance of object level libraries is the retrieval problem. For many non-programmers, a human interface to a library (i.e. a reference librarian) is an acceptable, and often preferred retrieval interface. In general, program libraries are supported only by tools such as KWIC and grep lookups and not with human reference librarians. From a personal experience with an exception to this generalization--I have observed that the reactions of the users to the human supported and tool supported access methods are different, and that the tool support does not in fact capture much of the disambiguation and filtering that librarians provide. This has often lead to undermining of large libraries as the categorization, maintenance, and retrieval functions are often onerous to programmers who would rather enjoy the discovery feelings that come from writing their own solution. This is further complicated by the fact that project managers usually can only hire programmers, not reference librarians, and suffer from the "when all you have is a hammer the solution to every problem needs to be a nail" syndrome. > I think Brad Cox's idea, though, is to move the developer up closer to the > customer. To do this, though, requires a sound base to develop on -- which > falls back on the question of granularity (move the low-level up towards the > in-between level). It may be that the evidence of shrink-wrap software, 4GLs, etc. is indicating more customers moving closer to doing development themselves (assembling macros...) without realizing it, and that if intermediate granularity will be supported it may move from higher levels down, and not as quickly the other way around. It is still hard to say for sure. Scott McGregor