ld231782@longs.LANCE.ColoState.EDU (Lawrence Detweiler) (06/27/90)
----- >Actually I've always thought the best analogy for software development >is movie production. It shares many similarities. One of which is that some is B-grade and some is art. Unfortunately, what determines the success of a program or a movie is not based solely on its internal (the code) and external (the interface) aesthetic appeal. They are vulnerable to the degrading effects of preoccupation with the bottom line. If software development is like movie making, I have had the thought that programs are exactly opposite to Hollywood sets. A set has a flashy, majestic appearance from the front, but from behind there is nothing substantial. In a program, few have any idea of the subtle and magnificent webs of intricate interactions that lie between the choreography of twirling electrons in its wires to the parade of photons meeting our eyes. What complexities lie in a program that is mistaken by the user to be lying dormant! A program is an inside-out set. The only similarity between the two is that the viewer is blissfully unaware of some astonishing aspect. Of course, the ideal programs of the future _will_ be more like a movie sets, so that my standard of Excellence in Software can be more readily achieved: When the users say "there's more?!" and the programmers say "that's it?!" ld231782@longs.LANCE.ColoState.EDU
edrbtsn@iuvax.cs.indiana.edu (Ed Robertson) (06/27/90)
+-Concerning Is Programming R&D or Production?, Lawrence Detweiler said: | | >Actually I've always thought the best analogy for software development | >is movie production. It shares many similarities. | | If software development is like movie making, I have had the thought | that programs are exactly opposite to Hollywood sets. A set has a | flashy, majestic appearance from the front, but from behind there is | nothing substantial. In a program, few have any idea of the subtle | and magnificent webs of intricate interactions that lie between the | choreography of twirling electrons in its wires to the parade of | photons meeting our eyes. ... A program is an inside-out set. Unfortuantely, I've seen many "programs" (perhaps they could be called "systems", but to use either word is to defame those professionals who are true programers and system-builders) which remind me exactly of Hollywood sets. These things are "database applications" written, without proper design, for PCs. What has happened is that a variety of tools, such as dBASE and Paradox, have nice "interface builders" which, in the wrong hands, become mere "facade builders." People see menus, multi-colored displays, and whiz-bang functions keys and perceive an effective system, even though there may be "nothing substantial" behind. It used to be the case that printing on 11 by 14 edge-punched paper had authority because it was computer output. Now that same mystique has moved to the input side too. -- Edward Robertson robertson@cs.indiana.edu Computer Science Dept Indiana University 812-855-4954 Bloomington, IN 47405-4101
kling@ICS.UCI.EDU (Rob Kling) (06/28/90)
Hi .... I saw your note about PC database systems badly "designed" ....... I've been teaching an IS course which includes a segment on database design, using paradox. (I also use Paradox for a variety of small systems on a research porject I direct). Paradox has a neat interface, but is awful in porviding suppport for porgram development & documentation (e.g., lacks a good interactive editor to facilitate documentation, and tools to locate x-refed variables, etc.) I've talked with deisgners of mincomputer relational products like INgress, and they claim that the lousy environments behind the pC porducts are also typical of relational database amangers for minis. Products like Paradox, Dbase, etc. INVITE bad designs ... even though I prefer them to C for writing database systems. (grin) There are a number of books about Paradox & 3 million similar books about Dbase, etc. These books teach the mechanics of the systems, much in the way that pascal & C books teach about language features rather than software design in language X. On this campus, the administratyion is developing a number of inofrmation systems in Revelation ... using student porgrammers who are not trained in IS design .... you can imagine the quality of the resulting porducts .... I have yet to see a good book on the design of database systems that is aimed at highly interactive products (rather than at transaction-oriented mainframe systems). Have you seen anything of use for professionals or students of this kind? Rob Kling UC-Irvine
mcgregor@hemlock.Atherton.COM (Scott McGregor) (06/29/90)
+-Concerning Is Programming R&D or Production?, Lawrence Detweiler said: | | >Actually I've always thought the best analogy for software development | >is movie production. It shares many similarities. | | If software development is like movie making, I have had the thought | that programs are exactly opposite to Hollywood sets. A set has a | flashy, majestic appearance from the front, but from behind there is | nothing substantial. In a program, few have any idea of the subtle | and magnificent webs of intricate interactions that lie between the | choreography of twirling electrons in its wires to the parade of | photons meeting our eyes. ... A program is an inside-out set. I think that this characterization underappreciates the technical aspects of a set. In order to produce just the right shadows extra lights may be moved in and hung. Wind machines, and rain machines may be used. Cameras and equipment have to be positioned in just the right way, not only to get the right feel, but to make sure lights and microphones don't show up in edges of the frames of each shot. A set is more than false front buildings just as a program is more than its window display. When both are stripped from their context they both appear flashy, majestic in front and insubstantial from behind. But in their contexts (a movie shoot or program) they are both subtly beautiful in management of "magnificent webs of intricate interactions" and choreography. While set designers and programmers find great beauty in their designs, they also acknowledge ugly masses of unfortunate compromises to reality and market conditions that are required. More importantly, to the people on the shoot, the set has a "meaning" different from the meaning that the audience feels when the watch the movie. To those who participated, the meaning is in the telling of the tale, to those who view it is the tale itself. Similarly, to programmers, the "meaning" of the system is intimately tied to the internal algorithm and data represenation choices that combine to "solve" the users problem. To the user the meaning is merely the problem solution itself. A good set is "opaque"--it hides the reality of the movie production process from the viewer who is thus able to suspend disbelief and temporarily live in the apparent virtuality being displayed. A good program can do the same--it can hide complexity from the user who doesn't want to know HOW it was done, and provide them a simplified model that they can treat as if it were real. Seeing a program as an inside-out set may provide some valuable insights, but it misses much of what can be learned from another field that has much to do with managing complexity on large scales and molding abstractions into concrete realizations. Scott McGregor mcgregor@atherton.com