nichols@ssd.kodak.com (Tim Nichols (37894)) (05/06/91)
I have been interested and occasionaly amused at the blather posted
recently about whether or not software can be engineered. Certainly it
_can_ be engineered; meatloaf _can_ be engineered, but it is subjected
to engineering only slightly less often than software {:-)}.
Engineering as a discipline refers to a rigorous process used to manage
the complexity of a solution to a given problem domain. I recently
built a patio beside my house. While a great deal of artistry and
construction effort went into it, there was almost no engineering
effort at all. The problem domain was not sufficiently complex to
warrent engineering. I was able to hold the entirety of the problem
and the intended solution in my brain at one time.
So it is with software. Historically, software solutions were applied
to problems of relatively small complexity. The common thread of
successful software projects was that the entirety of the program under
development was held in the brain of one or two key individuals.
Therefore, these projects required very little engineering.
Today we are faced with ever increasing complexity in the software
systems we build. We require abstractions, models, protocols, standard
components and interfaces, etc. in order to manage that complexity.
Whether conciously or not, we are introducing and defining the
discipline of engineering software as we go. It's a matter of
survival.
Art and Engineering are the endpoints of a continuum. The question is
not whether building software is an art or an engineering discipline.
It is ultimately both. The problem is that at present the engineering
half of the software continuum is vaporware. However, it is through
the work of the engineer "wanna-be"s that the continuum will be
defined.
Once the continuum is defined, will all of the software artisans be
taken out and shot? Of course not. There is plenty of room for all
the traditional role players we find in other disciplines today.
Software Scientists will fill the artisans role by continually pushing
the envelope. They will be the technology innovators.
Software Engineers will apply the state-of-the-art technology to
products and processes with precision and quality.
Software Technicians will be the hands-on support; the programmers.
The highly skilled work horses who prototype and build the dreams and
designs of the scientists and engineers.
I see no reason to expect that the evolution of the discipline of
software will differ markedly from the evolution of other technological
disciplines. To cling to this notion of software being somehow
different from its sibling fields is sophistry. It is a vanity
unbecoming of professionals.
And now, if you'll excuse me, I'll just step into something a little
less flammable
--
Tim Nichols Eastman Kodak Company
nichols@ssd.kodak.com Rochester, New York
"Opinions are my own, and do not reflect those of Kodak or its management" mcgregor@hemlock.Atherton.COM (Scott McGregor) (05/07/91)
In article <1991May6.165902.2116@ssd.kodak.com>, nichols@ssd.kodak.com (Tim Nichols (37894)) writes: ...(many good comments)... > Software Scientists will fill the artisans role by continually pushing > the envelope. They will be the technology innovators. > Software Engineers will apply the state-of-the-art technology to > products and processes with precision and quality. > Software Technicians will be the hands-on support; the programmers. > The highly skilled work horses who prototype and build the dreams and > designs of the scientists and engineers. > I see no reason to expect that the evolution of the discipline of > software will differ markedly from the evolution of other technological > disciplines. To cling to this notion of software being somehow > different from its sibling fields is sophistry. It is a vanity > unbecoming of professionals. I don't know if I disagree or not, but I am not quite so certain as you that Software as a technological discipline will wind up looking more like traditional engineering. At least one other possible path seems possible. At the end of the last century, filmaking was a very technical discipline. You had to be familiar with photo chemistry, lights, optics, the motion picture cameras, and the projectors. Filmakers were largely very technical people. Today, filmaking is still a very technical discipline, various sound systems, types of lenses, camera equipment, complex film developing techniques plus special effects require as much technical know how as ever. Yet the many engineers, and technicians are not in service of Film Scientists, but rather in service of Artistic Directors. There are many kinds of software, and it may well be that different parts of it go different ways. I could easily see systems that support analytical chemistry instruments, or systems that calculate trajectories going in the direction you describe, and at the same time, I can see systems aimed at increasing the capabilities of the average office worker to remember, to coordinate with others, etc. going the filmaking direction. This is an unpremeditated thought, but the difference may have to do with processing data vs. use of information as communication. The entertainment industries, broadcast radio & TV, and print media are all dominated by the alternative model that I mentioned. The Artistic Directors aim at maximizing the effectiveness of their communications to human individuals. The Scientists aim at maximizing their effective analysis of data. I am not sure that this is right even after considering it, but I'm not sure it is wrong either. We may be experiencing something similar to the debates that occur when behavioral scientists meet with physical scientists and try to describe what "science" is. The vary nature of the topics of study encourages a discrepancy in what they perceive science to be. Scott McGregor mcgregor@atherton.com
rsd@sei.cmu.edu (Richard S D'Ippolito) (05/08/91)
Some interesting points, Tim, but I believe that you have one thing exactly backwards: In article <1991May6.165902.2116@ssd.kodak.com> Tim Nichols writes: >Software Scientists will fill the artisans role by continually pushing >the envelope. They will be the technology innovators. > >Software Engineers will apply the state-of-the-art technology to >products and processes with precision and quality. In traditional engineering disciplines, the engineers have pushed the state of the practice with both innovative technology and innovative applications. The engineers backed off only when the technology failed. It was always left to the scientists to explain (sometimes many years later) why a particular technology succeeded or failed. Consider bridges and the airplane. Current software science will not be improved without good engineering examples (successes and failures). Rich -- "Please keep in mind that the ultimate goal [of hi-fi] is the reproduction of art, and that the invocation of science, while a neat parlour trick, is often unnecessary, flawed, and unreasonable." -- name mercifully withheld... rsd@sei.cmu.edu
nichols@ssd.kodak.com (Tim Nichols (37894)) (05/09/91)
In article <35177@athertn.Atherton.COM> mcgregor@hemlock.Atherton.COM (Scott McGregor) writes: >In article <1991May6.165902.2116@ssd.kodak.com>, nichols@ssd.kodak.com >(Tim Nichols (37894)) writes: >...(many good comments)... > >> Software Scientists will fill the artisans role by continually pushing >> the envelope. They will be the technology innovators. > >> Software Engineers will apply the state-of-the-art technology to >> products and processes with precision and quality. > >> Software Technicians will be the hands-on support; the programmers. >> The highly skilled work horses who prototype and build the dreams and >> designs of the scientists and engineers. > >> I see no reason to expect that the evolution of the discipline of >> software will differ markedly from the evolution of other technological >> disciplines. To cling to this notion of software being somehow >> different from its sibling fields is sophistry. It is a vanity >> unbecoming of professionals. > >I don't know if I disagree or not, but I am not quite so certain as you that >Software as a technological discipline will wind up looking more like >traditional engineering. At least one other possible path seems possible. >At the end of the last century, filmaking was a very technical discipline. >...(stuff deleted)... >There are many kinds of software, and it may well be that different >parts of it go different ways. I could easily see systems that support >analytical chemistry instruments, or systems that calculate trajectories >going in the >direction you describe, and at the same time, I can see systems aimed at >increasing the capabilities of the average office worker to remember, to >coordinate with others, etc. going the filmaking direction. > ...(more stuff deleted)... >Scott McGregor >mcgregor@atherton.com You make a valid point, but I contend that filmmaking is the wrong analogy to apply. Films largely try to educate and/or entertain. The vast majority of software does not (excepting video games and the like). A good film should be memorable; good software should not even be noticed. (someone stated this in an earlier thread, but I can't remember who) Given that the vast bulk of software we build and use is dedicated to helping us work smarter and faster, to have it be memorable would be cumbersome. I contend that a better anaology would be the role of a building architect. A building architect is aware of the technical aspects of construction, but his design effort is focused on how people interact with the building. In a similar vein, the software architect should be focused on how people interact with the system. Once the architecural design has been completed, the technical engineers will apply their processes to insure that the building (or software system) won't fall down. The role of the software architect was missing from my original post. This person requires a unique blend of engineering, artistic, and cognitive awareness skills to design systems which interact well with people, and are still readily engineered from a system structure perspective. -- Tim Nichols Eastman Kodak Company nichols@ssd.kodak.com Rochester, New York "Opinions are my own, and do not reflect those of Kodak or its management"
rothstei@mcs.kent.edu (Michael Rothstein) (05/09/91)
In article <35177@athertn.Atherton.COM> mcgregor@hemlock.Atherton.COM (Scott McGregor) writes: >In article <1991May6.165902.2116@ssd.kodak.com>, nichols@ssd.kodak.com >(Tim Nichols (37894)) writes: >...(many good comments)... > >> Software Scientists will fill the artisans role by continually pushing >> the envelope. They will be the technology innovators. > >> Software Engineers will apply the state-of-the-art technology to >> products and processes with precision and quality. > >> Software Technicians will be the hands-on support; the programmers. >> The highly skilled work horses who prototype and build the dreams and >> designs of the scientists and engineers. > >> I see no reason to expect that the evolution of the discipline of >> software will differ markedly from the evolution of other technological >> disciplines. To cling to this notion of software being somehow >> different from its sibling fields is sophistry. It is a vanity >> unbecoming of professionals. > >I don't know if I disagree or not, but I am not quite so certain as you that >Software as a technological discipline will wind up looking more like >traditional engineering. At least one other possible path seems possible. >At the end of the last century, filmaking was a very technical discipline. >You had to be familiar with photo chemistry, lights, optics, the motion >picture cameras, and the projectors. Filmakers were largely very >technical people. >Today, filmaking is still a very technical discipline, various sound >systems, types of lenses, camera equipment, complex film developing >techniques plus special effects require as much technical know how as >ever. Yet the many engineers, and technicians are not in service of >Film Scientists, but >rather in service of Artistic Directors. > (Many excellent thoughts on the future evolution as art/craft of software development deleted to try to approach some reasonable size ;-)) Following this (and other) thread(s) in this group made me think: it may be that the simile to follow when building software is more like building buildings. Consider: a building is first designed by an ARTIST (the architect) who, though somewhat knowledgeable on the limitations of his materials, really needs an expert to help him: a civil engineer, who can figure out the stresses of the suggested materials and structures: the two specialties interact and negotiate a final design satisfactory to both. The last stage, of course, is actual implementation. To continue this thought, how would the following scenario work?: A SOFTWARE ARCHITECT would be in charge of developing the (functional) requirements and user interface of the proposed system: he would be in communication with a software designer (aka software engineer) who would correct the requirements and interface design, and would later issue the specifications (aka non-functional requirements) to complete the problem definition stage. This stage would be subject to a review session and a final (contract) signing. The remainder of the software lifecycle could continue on as before, with a design (done by the some software designer/engineer, not necesarily the same one), walkthroughs, review, etc. etc. Though I personally feel that this idea of a software architect is a necesary one, I owuld be interested in other people's reactions. Thank you for reading this far and for any responses! -- Michael Rothstein (Kent State U)| If cars want to kill themselves, (rothstei@cs.kent.edu) | that's their problem: what I can't | understand is why they keep doing it (std. disclaimer) | with people inside. (Mafalda (Quino))
rothstei@mcs.kent.edu (Michael Rothstein) (05/09/91)
In article <1991May9.124559.2924@ssd.kodak.com> nichols@ssd.kodak.com (Tim Nichols (37894)) writes: >I contend that a better anaology would be the role of a building architect. >A building architect is aware of the technical aspects of construction, but >his design effort is focused on how people interact with the building. In a >similar vein, the software architect should be focused on how people interact >with the system. Once the architecural design has been completed, the >technical engineers will apply their processes to insure that the building >(or software system) won't fall down. I had just finished editing my post when I saw this: I also tried to cancel my post but the software did not let me: at any rate this post answers my question, though I might add that some emphasis is needed on user interface design, which, IMHO, is one the most important products the software architect should develop. -- Michael Rothstein (Kent State U)| If cars want to kill themselves, (rothstei@cs.kent.edu) | that's their problem: what I can't | understand is why they keep doing it (std. disclaimer) | with people inside. (Mafalda (Quino))
nichols@ssd.kodak.com (Tim Nichols (37894)) (05/10/91)
In article <1991May9.160716.29500@mcs.kent.edu> rothstei@mcs.kent.edu (Michael Rothstein) writes: >In article <1991May9.124559.2924@ssd.kodak.com> nichols@ssd.kodak.com (Tim Nichols (37894)) writes: >>I contend that a better anaology would be the role of a building architect. >>A building architect is aware of the technical aspects of construction, but >>his design effort is focused on how people interact with the building. In a >>similar vein, the software architect should be focused on how people interact >>with the system. Once the architecural design has been completed, the >>technical engineers will apply their processes to insure that the building >>(or software system) won't fall down. > >I had just finished editing my post when I saw this: I also tried to cancel >my post but the software did not let me: at any rate this post answers my >question, though I might add that some emphasis is needed on user interface >design, which, IMHO, is one the most important products the software >architect should develop. >-- >Michael Rothstein (Kent State U)| If cars want to kill themselves, I couldn't agree more. The design emphasis is primarily on user interface from an implemenation perspective. I always emphasize the notion of "human interaction" to my students because as designers we sometimes forget that there are human beings that ultimately have to cope with all those multi-colored widgets on the screen. -- Tim Nichols Eastman Kodak Company nichols@ssd.kodak.com Rochester, New York "Opinions are my own, and do not reflect those of Kodak or its management"
chrisp@regenmeister.EBay.Sun.COM (Chris Prael) (05/10/91)
From article <25170@as0c.sei.cmu.edu>, by rsd@sei.cmu.edu (Richard S D'Ippolito): > Some interesting points, Tim, but I believe that you have one thing exactly > backwards: > In article <1991May6.165902.2116@ssd.kodak.com> Tim Nichols writes: > >Software Scientists will fill the artisans role by continually pushing > >the envelope. They will be the technology innovators. > >Software Engineers will apply the state-of-the-art technology to > >products and processes with precision and quality. > In traditional engineering disciplines, the engineers have pushed the state > of the practice with both innovative technology and innovative applications. > The engineers backed off only when the technology failed. It was always > left to the scientists to explain (sometimes many years later) why a > particular technology succeeded or failed. Consider bridges and the > airplane. > Current software science will not be improved without good engineering > examples (successes and failures). Rich makes exactly the right points, very accurately. Anyone who is willing to understand the relationship between science and engineering in any field needs to understand what he said here. The thing that originally attracted my attention is the title of this thread: Art vs. Engineering. It is, simply, wrong. Engineering IS art. Good engineering is good art and bad engineering is bad art. There is, and can be, no versus to the relationship between art and engineering. This statement becomes abundantly clear is you compare, for example, the East German Trabant to the Honda Civic. Closer to home, compare BASIC to C. C is great engineering and great art. What BASIC became on PCs is an embarrasment to our field. No engineer functions without an aesthetic sense. Some software engineers' aesthetic sense is pretty crude, others are artists on a par with Brunel (the English civil and mechanical engineer), Jano (the great Italian engineer of car engines), Chapman (the brilliant English chassis engineer), or Picasso (the famous painter). My personal view is that the current state of the visual arts has been caused by most of the potential great artists having gone into various fields of engineering instead of the visual arts for the last 100 years. Chris Prael
dlw@Atherton.COM (David Williams) (05/10/91)
In article <1991May9.124559.2924@ssd.kodak.com>, nichols@ssd.kodak.com (Tim Nichols (37894)) writes: >In article <1991May6.165902.2116@ssd.kodak.com>, nichols@ssd.kodak.com >(Tim Nichols (37894)) writes: >...(many good comments)... > Scott Mcgregor writes: In article <35177@athertn.Atherton.COM> mcgregor@hemlock.Atherton.COM (Scott McGregor) writes: >I don't know if I disagree or not, but I am not quite so certain as you that >Software as a technological discipline will wind up looking more like >traditional engineering. At least one other possible path seems possible. >At the end of the last century, filmaking was a very technical discipline. >...(stuff deleted)... >There are many kinds of software, and it may well be that different >parts of it go different ways. I could easily see systems that support >analytical chemistry instruments, or systems that calculate trajectories >going in the >direction you describe, and at the same time, I can see systems aimed at >increasing the capabilities of the average office worker to remember, to >coordinate with others, etc. going the filmaking direction. > ...(more stuff deleted)... >Scott McGregor >mcgregor@atherton.com Tim Nichols responds: >You make a valid point, but I contend that filmmaking is the wrong analogy to >apply. Films largely try to educate and/or entertain. The vast majority of >software does not (excepting video games and the like). A good film should >be memorable; good software should not even be noticed. (someone stated this I'm not sure I buy this...while you are sitting in a theatre experiencing a film if it is a good/entertaining/interesting one you are generally not thinking hey I am watching a film. The filmmaker draws you in so you feel a part of the proceedings. After you exit the theatre you will probably remember a good experience with the film--why is it not reasonable to have the same feeling on leaving your workstation after using a well designed software package? I mean other than nfs (which one becomes aware of when stale handles occur) and other kinds of OS service level software what examples of "stealth" software do you have to draw on? >Given that the vast bulk of software we build and use is dedicated to helping >us work smarter and faster, to have it be memorable would be cumbersome. Perhaps if it is memorable it is encouraging habit creation and preservation. These days it seems more like working faster is as a result of hardware performance improvements rather than software improvements. >I contend that a better anaology would be the role of a building architect. >A building architect is aware of the technical aspects of construction, but >his design effort is focused on how people interact with the building. In a >similar vein, the software architect should be focused on how people interact >with the system. Once the architecural design has been completed, the >technical engineers will apply their processes to insure that the building >(or software system) won't fall down. >The role of the software architect was missing from my original post. This >person requires a unique blend of engineering, artistic, and cognitive >awareness skills to design systems which interact well with people, and >are still readily engineered from a system structure perspective. Sounds reasonable, but I like the film analogy as well, perhaps because it might get us to improve how we interact with our user community. I mean, notice that we don't have user MANUALS and training classes for either films or video games? >-- > Tim Nichols Eastman Kodak Company > nichols@ssd.kodak.com Rochester, New York David Williams "Another one of those strange guys at Atherton Technology"
mcgregor@hemlock.Atherton.COM (Scott McGregor) (05/10/91)
In article <1991May9.124559.2924@ssd.kodak.com>, nichols@ssd.kodak.com (Tim Nichols (37894)) writes: >You make a valid point, but I contend that filmmaking is the wrong analogy to >apply. Films largely try to educate and/or entertain. The vast majority of >software does not (excepting video games and the like). Of course, not all films are art or entertainment films. As Tim notes, film is a common medium for education, and communication as well. Considerable amounts of user oriented software has these as dominant attributes as well. For example, there are structured design and structured analysis CASE tools such as from Cadre and IDE. Part of what they offer is that they are *communicating* to you information from their "experts" with the hope of *educating* you in currently recognized techniques for improved design and analysis. The software not only educates you, but helps you in the formation of presumably beneficial design habits. For user oriented software, a growing amount of the product is not merely the manipulation that the software does, but also its user manual, on line help, computer based training, off-line training, and design aspects which make it easy to learn, and (contrary to what Tim stated below) to easy to remember how to use. Additionally, in a competative commercial market, there is value in a product which is "entertaining" over a competing product with the same capability but without the endearing facade. This doesn't always mean that "entertainment" is frivolous, but some features give people a "good feeling". The macintosh user interface, including its "entertaining" as well as educational guided tour is a frequently cited example. One can also determine a general common preference for the HP widgets 3D appearance version over their 2D versions, despite the fact that they behave the same way, and have approximately the same visual recognition rates. > A good film should >be memorable; good software should not even be noticed. (someone stated this >in an earlier thread, but I can't remember who) > Given that the vast bulk of software we build and use is dedicated to helping > us work smarter and faster, to have it be memorable would be cumbersome. I believe that this is an over simplification. It is important to distinguish the use of long term memory from short term memory. People don't have much short term memory (by analogy, we only have a few registers). Thus it is very important to avoid overloading that short term memories with tasks that relate to the software, and not to the underlying task. If a software product is not memorable, you will be forced to relearn it every time you use it, and this learning (and transitory remembering of which button does which function) competes with the underlying task for short term memory, and degrades the task performance--introducing not only delay, but frequently also introducing error as well, and of course the well known "now where was I?" phenomenon (swapping). To avoid this problem, it can be claimed that good software should not be noticed. This is true, though the way it is most likely to be achieved is through the use of "long term memory", generally in the form of habits. Because people are able to handle much more long term memory, there is not the kind of interaction problems as when short term memory is being competed for. Habit formation is critical for "seemingly effortless" performance of complex tasks using complex tools. In this respect, the memorability of many software features, like a good movie, is critical to success. (There is considerable literature on this point, I particularly like Norman, Schniederman, Nelson, and Malone's papers that touch on these points. But for a short often used example, consider learning to drive an automobile. Until you build habits, driving is a very engrossing activity--it is hard to even control your speed. Once you develop the habits, it is possible to drive and do other things as well, such as carry on a conversation. There is still some interaction, and tests can show that both activities may be degraded over what can be done if doing only one. But even so, performance levels are significantly higher than during the pre-habit formation learning period. And then of course, it is fair play to re-use existing learned complex habits, such as in using the same sort of steering mechanism and accelerator pedal in a speed boat. Good software also takes advantage of these existing memorable habits). So I would conclude that given software aimed at making us work smarter and faster it is *crucial* that we learn to make it more memorable and enjoyable to use. > I contend that a better anaology would be the role of a building architect. > A building architect is aware of the technical aspects of construction, but > his design effort is focused on how people interact with the building. In a > similar vein, the software architect should be focused on how people interact > with the system. Once the architecural design has been completed, the > technical engineers will apply their processes to insure that the building > (or software system) won't fall down. > The role of the software architect was missing from my original post. This > person requires a unique blend of engineering, artistic, and cognitive > awareness skills to design systems which interact well with people, and > are still readily engineered from a system structure perspective. This is a very provocative alternative that I think deserves considerable thought. As you point out, an architect model requires a person that combines both the technical and artistic aspects in one person, and this is very different from the scientist model in the original article. It may be a better model, or it may merely be a model which is better for an additional subdomain. In my previous posting, I identified a domain where the software scientist model was perhaps more appropriate, and one where an artistic model might be more appropriate. The building architect model is interesting in that buildings are physical objects, just computers are. An architecture model might be very appropriate for a systems integrator house which is concerned with soup-to-nuts hardware + software solutions. But the filmaker model has its merits too, in that buildings, and their architectural drawings are more static, whereas film and many forms of software (including all the computer based and off line training capablities) are more concerned with dynamic ephemeral fleeting images. Perhaps for some task domains, the interactivity demanded of the software is more akin to the "quick cuts" techniques of filmmaking. If so, does this put additional artistic demands upon the designer which over task someone who must also be designing from a technical point of view> Might this be another way of saying that the software industry is really many industries, and that the dominant factor affecting organization of the development team is end market for which the software is targetted? (Johnathan Grudin's article in April 1991 Computer comes to mind). Perhaps what this really argues for is a continuum of development approaches from the pure technical dominant (scientist) driven model, through the mixed art/technical (architect) model to the pure art dominant model (filmmaker)? Scott McGregor Atherton Technology mcgregor@atherton.com
rh@smds.UUCP (Richard Harter) (05/13/91)
In article <1312@grapevine.EBay.Sun.COM>, chrisp@regenmeister.EBay.Sun.COM (Chris Prael) writes: > C is great engineering and great art. Thanks for a good laugh. C is to great engineering what doggerel is to poetry. -- Richard Harter, Software Maintenance and Development Systems, Inc. Net address: jjmhome!smds!rh Phone: 508-369-7398 US Mail: SMDS Inc., PO Box 555, Concord MA 01742 This sentence no verb. This sentence short. This signature done.
daves@hpopd.pwd.hp.com (Dave Straker) (05/13/91)
> The thing that originally attracted my attention is the title of this > thread: Art vs. Engineering. It is, simply, wrong. Engineering IS > art. Good engineering is good art and bad engineering is bad art. > There is, and can be, no versus to the relationship between art and > engineering. > > Chris Prael This is probably a matter of interpretation. I would define Art as being based in 'feelings' and Science as been based in 'rules'. If there is a key word I would use for Engineering, it would be 'pragmatic'. Do what works. This would tend to push it towards the Science end of the spectrum, although there are still elements where 'feeling' is appropriate - such as in the design of a user interface. Perhaps where confusion is caused is when feelings are based in rules, for example where an engineer does what 'feels right', and is right - it feels right because he has internalised the rules to the point where he does not or even cannot describe them. Dave Straker Pinewood Information Systems Division (PWD not PISD) [8-{) HPDESK: David Straker/HP1600/01 Unix: daves@hpopd.pwd.hp.com
kambic@iccgcc.decnet.ab.com (George X. Kambic, Allen-Bradley Inc.) (05/14/91)
In article <1991May9.155632.29277@mcs.kent.edu>, rothstei@mcs.kent.edu (Michael Rothstein) writes: > In article <35177@athertn.Atherton.COM> mcgregor@hemlock.Atherton.COM (Scott McGregor) writes: >>In article <1991May6.165902.2116@ssd.kodak.com>, nichols@ssd.kodak.com >>(Tim Nichols (37894)) writes: [...] > A SOFTWARE ARCHITECT would be in charge of developing the (functional) > requirements and user interface of the proposed system: he would be in > communication with a software designer (aka software engineer) who would > correct the requirements and interface design, and would later issue the > specifications (aka non-functional requirements) to complete the problem > definition stage. This stage would be subject to a review session and > a final (contract) signing. > The remainder of the software lifecycle could continue on as before, > with a design (done by the some software designer/engineer, not necesarily > the same one), walkthroughs, review, etc. etc. Many of these concepts fail for two reasons. In reality, a person implementing a phase of the SW development lifecycle must have a working knowledge of other phases in order to be effective. In fact one of the only ways to really learn how to engineer SW is to spend time in each phase. Humbling. Secondly, there is a neglect of the reality of feedback and changes during the life cycle. No product development is done without change being incurred. Software is no different. Feedback, interaction, and communication are skills which are as fundamental to good SW engineering as SW design methods. Don't be an expert. Be a generalist. GXKambic standard disclaimer
jls@netcom.COM (Jim Showalter) (05/14/91)
>Secondly, there >is a neglect of the reality of feedback and changes during the life cycle. No >product development is done without change being incurred. Software is no >different. Feedback, interaction, and communication are skills which are as >fundamental to good SW engineering as SW design methods. Indeed, and the sad thing is that traditional methodologies completely ignore this simple reality--the classic "waterfall" model of software development assumes what I call a "top-down omniscient" process, which would work great if we could just find some omniscient engineers. In reality, either feedback is accomodated in an ad hoc manner during development (with consequent penalties in terms of efficiency, since the process is not explicitly set up to plan for such feedback) or, as is often the case, feedback is folded in during the inappropriately named "maintenance" phase. Fortunately, more realistic and effective methodologies do exist, and they tend to be much more flexible, iterative, and oriented toward producing prototypes instead of piles of fictive "documentation". These newer approaches can even be used on projects subject to 2167A constraints, if an appropriate tailoring is chosen. -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 ***************** * Proven solutions to software problems. Consulting and training in all aspects* * of software development. Management/process/methodology. Architecture/design/* * reuse. Quality/productivity. Risk reduction. EFFECTIVE OO techniques. Ada. *
dedek@meaddata.com (Mike Dedek) (05/14/91)
In article <1991May9.124559.2924@ssd.kodak.com>, nichols@ssd.kodak.com (Tim Nichols (37894)) writes: <<stuff about photography/compsci parallels deleted>> |> |> You make a valid point, but I contend that filmmaking is the wrong analogy to |> apply. Films largely try to educate and/or entertain. The vast majority of |> software does not (excepting video games and the like). A good film should |> be memorable; good software should not even be noticed. (someone stated this |> in an earlier thread, but I can't remember who) |> |> Given that the vast bulk of software we build and use is dedicated to helping |> us work smarter and faster, to have it be memorable would be cumbersome. |> |> I contend that a better anaology would be the role of a building architect. |> A building architect is aware of the technical aspects of construction, but |> his design effort is focused on how people interact with the building. In a |> similar vein, the software architect should be focused on how people interact |> with the system. Once the architecural design has been completed, the |> technical engineers will apply their processes to insure that the building |> (or software system) won't fall down. |> |> The role of the software architect was missing from my original post. This |> person requires a unique blend of engineering, artistic, and cognitive |> awareness skills to design systems which interact well with people, and |> are still readily engineered from a system structure perspective While your point is largely true, consider the science of photography for astronomy or military applications. Although many consider the end result 'art', the process of obtaining these pictures (e.g., satellite pictures of military installations in detail, night-vision, that big telescope NASA just sent up) is very scientific. I submit that compsci is similar to photography; there will be applications which are more 'scientific' and those which are more 'artistic'. The line differentiating these is blurred. The really great breakthroughs in compsci will be at least partly artistic, because they will be so radically different from the status quo that some creative effort will be necessary. I could digress for pages, but I won't. | I'm too lazy to create a .sig file, so I just type this in every | time I mail! | Opinions are solely those of the author. | Have fun!
b-davis%cai.utah.edu@cs.utah.edu (Brad Davis) (05/14/91)
Software creation is a craft, as in the great crafts of the ancient world. Even the most talented "artist" needs to study, refine, and hone his/her work and the most talented begining "artist" is still a poor software writer. On the other side, there are no hard and fast, tried and true rules that will create great software as there is in the sciences and engineering to create new entities. -- Brad Davis ..!uunet.uu.net!cs.utah.edu!cai.utah.edu!b-davis b-davis@cs.utah.edu, b-davis@cai.utah.edu One drunk driver can ruin your whole day.
lws@comm.wang.com (Lyle Seaman) (05/15/91)
dlw@Atherton.COM (David Williams) writes: >Sounds reasonable, but I like the film analogy as well, perhaps because it >might get us to improve how we interact with our user community. I mean, >notice that we don't have user MANUALS and training classes for either >films or video games? Ahh, but there ARE user manuals for video games... Have been ever since the games got tricky, instead of just faster. One of the first was for PacMan, I think. They're usually not written by the vendor. -- Lyle 508 967 2322 lws@wang.com Wang Labs, Lowell, MA, USA
jane@latcs2.lat.oz.au (Jane Philcox) (05/15/91)
In article <36650010@hpopd.pwd.hp.com> daves@hpopd.pwd.hp.com (Dave Straker) writes: >> The thing that originally attracted my attention is the title of this >> thread: Art vs. Engineering. It is, simply, wrong. Engineering IS >> art. Good engineering is good art and bad engineering is bad art. >> There is, and can be, no versus to the relationship between art and >> engineering. >> >> Chris Prael > >This is probably a matter of interpretation. I would define Art as >being based in 'feelings' and Science as been based in 'rules'. >If there is a key word I would use for Engineering, it would be >'pragmatic'. Do what works. This would tend to push it towards >the Science end of the spectrum, although there are still elements >where 'feeling' is appropriate - such as in the design of a user interface. What you're talking about, Dave, is the feelings of the person who is doing the engineering. IMHO, the feelings of the observers are more important in distinguishing what is art. I think that both artists and engineers feel similarly when they are practising their respective crafts. In art, too, there are techniques, some of which work and some of which don't (Try thinning oil paint with water! Or writing a sonnet with 17 lines. The results may be interesting, but far from what you intended.), some of which can be taught to anyone, and some of which definitely can't. There are also known techniques, which can usually be taught, for the design of art objects. So, if you can talk about software design as "engineering", then in that sense art is engineering. But the result generally depends on a combination of talent _and_ technique, and when both are of a high order, the feeling induced in the observer is "This is beautiful." But a fine car, a bridge, an aeroplane, and other products of engineering, can all be beautiful too. So in that sense engineering is art. And not all engineers can produce equally beautiful results. The results also depend on talent. >Perhaps where confusion is caused is when feelings are based in >rules, for example where an engineer does what 'feels right', and >is right - it feels right because he has internalised the rules to >the point where he does not or even cannot describe them. Artists do this too, both in design and execution of their work. In fact, many people don't realize that for almost any art form there are techniques (rules, if you like) that have to be learned, and that the "self-taught" or "natural" artist has usually spent a number of years acquiring these techniques on a cut-and-try basis. So that when s/he does what "feels right", s/he has a solid background of technique (the rules are internalised) to base the work on. Regards, Jane. -- -------------------------------------------------------------------- Six lawyers up to their necks in sand is defined as not enough sand. --------------------------------------------------------------------
wdr@wang.com (William Ricker) (05/15/91)
lws@comm.wang.com (Lyle Seaman) writes: >dlw@Atherton.COM (David Williams) writes: >>notice that we don't have user MANUALS and training classes for either >>films or video games? >Ahh, but there ARE user manuals for video games... Have been ever >since the games got tricky, instead of just faster. One of the >first was for PacMan, I think. They're usually not written by the vendor. VidGames also have printed and online documenation supplied by the vendor. Online: The sequences (random or canned) through which the machine cycles while waiting for the victim, er, customer to insert quarter(s) Printed: Some small amount of lettering on the facade (typically an iconic glossary of the items which give special points/abilities, and if the different phases have different goals, listing those) These combine to provide a minimal familiarization with the method of operation before you first grab hold of the manipulator (be it a joy-stick, trackball, or uzi-clad lightpen). Of course, the videogame operators (and thus the manufacturers) benefit from the ground-school training provided by print documen- tation & demo loop being just barely inadequate -- so that the customer must feed endless quarters to get on-the-job-training before making the assault on the top-scorers' list. Some intermittent positive reinforcement is necessary, of course -- just as with slot machines -- to keep the player's attention. (Standard Psych 101/110 here!) If we were marketing the game as a software product for non-entertainment use, this level of documentation would be found inadequate by our users. -- /s/ Bill Ricker wdr@wang.wang.com "The Freedom of the Press belongs to those who own one." *** Warning: This account is not authorized to express opinions. ***
chrisp@regenmeister.EBay.Sun.COM (Chris Prael) (05/16/91)
From article <1991May13.181826.18832@hellgate.utah.edu>, by b-davis%cai.utah.edu@cs.utah.edu (Brad Davis): > Software creation is a craft, as in the great crafts of the ancient > world. This is as true (and as inaccurate) of building software is it is of building automobiles, disk drives, or high rise buildings. > Even the most talented "artist" needs to study, refine, and > hone his/her work and the most talented begining "artist" is still a > poor software writer. Very true and very said! > On the other side, there are no hard and fast, > tried and true rules that will create great software as there is in > the sciences and engineering to create new entities. Where did you get the idea that " hard and fast, tried and true rules" can produce great engineering? Wake up and look around you. "Hard and fast, tried and true" produced the same pedestian garbage in structural engineering, mechanical engineering, and electronic engineering as it does in programming. Too many people mistakenly believe that designing software is somehow magically different from other forms of engineering. Chris Prael
kambic@iccgcc.decnet.ab.com (George X. Kambic, Allen-Bradley Inc.) (05/16/91)
In article <1312@grapevine.EBay.Sun.COM>, chrisp@regenmeister.EBay.Sun.COM (Chris Prael) writes: > From article <25170@as0c.sei.cmu.edu>, by rsd@sei.cmu.edu (Richard S D'Ippolito): > Engineering IS > art. Good engineering is good art and bad engineering is bad art. > There is, and can be, no versus to the relationship between art and > engineering. ? Equivalencing engineering to art does not work except from the point of view of manipulating the local environment. Is it a consequence of good engineering practices that the result generally looks pleasing to the eye? Or does an item with good engineering become pleasing to the eye and mind after understanding how well it satisfies form, fit, and function. Is an F-4 good art? Don't think many people would classify it that way, but is it good engineering? Do believe so, and once you begin to appreciate that fact, it becomes mentally and visually pleasing. GXKambic standard disclaimers
styri@cs.hw.ac.uk (Yu No Hoo) (05/16/91)
In article <1991May13.181826.18832@hellgate.utah.edu> b-davis%cai.utah.edu@cs.utah.edu (Brad Davis) writes: >Software creation is a craft, as in the great crafts of the ancient >world. Even the most talented "artist" needs to study, refine, and >hone his/her work and the most talented begining "artist" is still a >poor software writer. On the other side, there are no hard and fast, >tried and true rules that will create great software as there is in >the sciences and engineering to create new entities. I really like Brad's use of the word "craft" in this context. (However, I still think there is software engineering.) But I would like someone to elaborate on these "hard and fast, tried and true rules" which seem to exist in the sciences and engineering. How about comparing the software craftsman to the old stonemason. Take a look at any mediveal cathedral. Sure, some of these buildings stand only by chance and lycky "artistry" - but usually followed strict rules and principles, bulding to specification. That didn't stop them carving beautiful stones and creating wonderful buildings. And, these people are kind of the fathers of all engineers. Being an engineer today does not exclude you from being a skilled craftsman as well, on the contrary - it'll probably make you a very good engineer. An engineer may also be "artistic" and good at finding creative solutions. The software engineer may still "carve" his beautiful code as long as the carving doesn't weaken the design of the system. However, too many "ornaments" in the code will result in expensive maintenance. The customer may require a less original construction. If you only want to carve beautiful code you may starve. (Probably you can then call yourself an artist - starving, but only working for a higher purpose. :-) ) Finally, do not confuse scientists and engineers. The purpose of a scientist is to solve problems in order to advance his science. The purpose of an engineer is of a far more practical nature. ---------------------- Haakon Styri Dept. of Comp. Sci. ARPA: styri@cs.hw.ac.uk Heriot-Watt University X-400: C=gb;PRMD=uk.ac;O=hw;OU=cs;S=styri Edinburgh, Scotland
iverson@xstor.com (Tim Iverson) (05/17/91)
In article <36650010@hpopd.pwd.hp.com> daves@hpopd.pwd.hp.com (Dave Straker) writes: >This is probably a matter of interpretation. I would define Art as >being based in 'feelings' and Science as been based in 'rules'. The definition of science is not open to interpretation: science is defined as anything that is founded on the scientific method. Engineering is the science of methods. The definition of art is open to interpretation, but most agree that the main goal of art is communication and that it is not based on feelings, but on aesthetics. It communicates feelings (among many other things); though some say if it doesn't move you, it isn't art. >If there is a key word I would use for Engineering, it would be >'pragmatic'. Engineering lies in the empirical as opposed to theoretical domain of science, but it is purely a science, not an art. It advances by applying new methods and testing the results against the results of old methods. >Perhaps where confusion is caused is when feelings are based in >rules, for example where an engineer does what 'feels right', and >is right - it feels right because he has internalised the rules to >the point where he does not or even cannot describe them. There is no confusion. If a programmer uses a methodology, he is an engineer. If not, then he is an artist (or a hack :-). The difference is that good engineering can be done by anyone that understands the methodology, whereas good art can only be created by someone with talent (i.e. innate understanding of both work and medium). I've been talking like the two are somehow antithetical - they are not. Just as pewter can be made from silver an tin, so can a program be alloyed of art and engineering. Which is tin and which is silver is obvious, but I'll leave it as an exercise for the flameproof :-). >Dave Straker Pinewood Information Systems Division (PWD not PISD) > Unix: daves@hpopd.pwd.hp.com - Tim Iverson iverson@xstor.com -/- uunet!xstor!iverson
tsarver@andersen.uucp (Tom Sarver) (05/17/91)
Hey guys, This thread is getting a little tiresome. Everyone is simply reacting based on their own experience. Like good scientists that we are, let's try to find some good references on the subject. Below I offer two references which deal directly with the debate, and I attempt to summarize them here. The conclusion of this posting is that software engineering is still pre-paradigm as evidenced by the lack of a generally agreed upon way of looking at software, AND the weakness of the supporting science, computer science. HOWEVER, software is such a gosh-dern useful thing, people are willing to shell out big bucks for sub-otpimal solutions. My first suggested reference is Thomas Kuhn's _The Structure of Scientific Revolutions_. This excellent book describes the life-cycle of a scientific discipline. The second reference is an article by Mary Shaw of Carnegie Mellon University, "Propsects for an Engineering Discipline of Software." This article examines a definition of engineering and relates it to software development and deployment. This article, BTW, received IEEE's award for best article of 1990. In _...Scientific Revolutions_, Kuhn describes a period called "pre- paradigm in which participants are attempting to model the results of emperical studies (formal and informal) into a paradigm. This paradigm enables them to discuss findings in a common arena of terms. The discipline matures when the paradigm is found to account for a large percentage of phenomena. The discipline then enters an "engineering" phase in which people use the results of the discipline to advance someone's external goals (society's, an evil genius', etc.) Mary Shaw implies, and I agree with her, that "software engineering" is in the pre-paradigm stage. Mary Shaw's article, "...Engineering Discipline of Software," Explains how a discipline develops from a craft, to production, and finally a professional engineering discipline. After showing the phases of software development (prog. any-which-way, prog-in-the-small, prog-in- the-large), she explains how inadequate computer science is to the way that software is currently developed. The conclusion is that we are in the "production" phase of the discipline. There are successful and unsuccessful examples of software development. But the science is not mature enough to move from requirements to code with unerring steps. Everyone who does it is drawing on knowledge, rules of thumb, experience, and intuition to pull it off. Whoever does software engineering is a craftsman with different freedoms and constraints. No one can determine unequivocally that a piece of software is "right" or "wrong." I'd like to see folks' opinions of these references and their applicability. Try to imagine what software engineering would be like if it were truly engineering. --Tom Sarver tsarver@andersen.com -- /----------------------------------->>*<<-------------------------------------+ | ____ | | Tom Sarver: tsarver@andersen.com | Only Amiga makes it possible! / / / | | "A real computer has a linear address space. NO 386's!!" / / / |
dedek@meaddata.com (Mike Dedek) (05/17/91)
In article <460@smds.UUCP>, rh@smds.UUCP (Richard Harter) writes: |> In article <1312@grapevine.EBay.Sun.COM>, chrisp@regenmeister.EBay.Sun.COM (Chris Prael) writes: |> |> > C is great engineering and great art. |> |> Thanks for a good laugh. C is to great engineering what doggerel is to |> poetry. This thread has been discussing whether software development (using the computer language 'C' in particular) is engineering or art, I believe. Since 'C' is a tool/method for software development, in the context of *this* discussion it can be likened to say, concrete. One can create both art and engineering using concrete, and sometimes both at the same time, but I wouldn't say (in *this* context) that concrete itself is either engineering or art. One can also create 'engineering doggerel' with concrete. Using this analogy, both statements cited above are invalid. One could say '*Software written in* 'C' is great engineering and great art', or '*Software written in* 'C' is to great engineering what doggerel is to poetry.' However, like a bridge created from concrete, software written in 'C' could be 'great engineering', 'great art', or 'doggerel' *depending on the engineer.* Even if one believes that 'C' is a poor, primitive, or unstructured engineering medium (like sticks), it is still possible to create works of art or engineering from it. It may be more difficult, or require more discipline by the engineer, but it can be done. Engineers should think before they work. They should also *think* before they post :-) | I'm too lazy to create a .sig file, so I just type this in every | time I send e-mail! | Opinions expressed are solely those of the author. | ...!uunet!meaddata!dedek ...dedek@moonlight.meaddata.com
chrisp@regenmeister.EBay.Sun.COM (Chris Prael) (05/18/91)
From article <1991May16.231300.13345@casbah.acns.nwu.edu>, by tsarver@andersen.uucp (Tom Sarver): > Hey guys, > This thread is getting a little tiresome. Everyone is simply reacting You find something wrong with applying the scientific method? > based on their own experience. Like good scientists that we are, let's > try to find some good references on the subject. Below I offer two Finding references may be academically sound, but I question its applicability to being a scientist. Scientists experiment. They also learn from other people's experiments. In that sense, most of the discussion in this thread has been scientific in character. > references which deal directly with the debate, and I attempt to > summarize them here. > In _...Scientific Revolutions_, Kuhn describes a period called "pre- > paradigm in which participants are attempting to model the results of > emperical studies (formal and informal) into a paradigm. This paradigm > enables them to discuss findings in a common arena of terms. The > discipline matures when the paradigm is found to account for a large > percentage of phenomena. The discipline then enters an "engineering" > phase in which people use the results of the discipline to advance > someone's external goals (society's, an evil genius', etc.) This is an interesting speculation, but it is historically inacurate, hence bad science. If you read the history of most scientific developments, particularly in physics, you will find that most of the major advances were the result of significant engineering advances. Major engineering advances, on the other hand, have come most often from advances in materials (engineering, though we now call it "material science", other engineering advances, or scientific advances). Most people studiously ignore the fact that Einstein's training was not in a scientific topic. His training was in examining patent applications, a non-academic form of engineering training. Chris Prael
eaker@ukulele.crd.ge.com (Charles E Eaker) (05/18/91)
In article <2996@odin.cs.hw.ac.uk> styri@cs.hw.ac.uk (Yu No Hoo) writes: >How about comparing the software craftsman to the old stonemason. Take a look at Ken Follet's "Pillars of the Earth". It's a wonderful novel set in the 12th century and contains an enormous amount of detail about the craft of cathedral building in the absence of an engineering profession. Has some great examples of how rules of thumb such as "To make it stronger, make it thicker," literally fall down. -- Chuck Eaker / P.O. Box 8, K-1 3C12 / Schenectady, NY 12301 USA eaker@crd.ge.com eaker@crdgw1.UUCP (518) 387-5964
lleone@fir16.cray.com (Larry Leone) (05/18/91)
Something I learned from my former days as an engineering student which I think applies equally well to the kind of programming I practice in industry today. en.gi.neer.ing - the art of applied science Think about this the next time you choose a sorting algorithm from the realm of computer science and artfully apply it to the problem at hand. my 2 cents, --Larry -- Larry Leone Internet: lleone@cray.com UUCP: uunet!cray!lleone
rh@smds.UUCP (Richard Harter) (05/18/91)
In article <4366@meaddata.meaddata.com>, dedek@meaddata.com (Mike Dedek) writes: > In article <460@smds.UUCP>, rh@smds.UUCP (Richard Harter) writes: > |> In article <1312@grapevine.EBay.Sun.COM>, chrisp@regenmeister.EBay.Sun.COM (Chris Prael) writes: > |> > C is great engineering and great art. > |> Thanks for a good laugh. C is to great engineering what doggerel is to > |> poetry. Mike discusses this at some length, making the distinction between tools and the things that they are built with. He draws analogies with building with concrete and sticks and such. His general point, which is well taken, is that one can do good software engineering even when working with poor tools. However he makes what I would consider to be a fundamental error in excluding tools and languages from the domain of engineering. Tools and languages are objects of design and specification just as much as specific programs and systems are. Indeed, good engineering of tools and languages is critical simply because they are continually reused. I will concede that my comments about C were snide (but accurate :-)). I do not concede that it is irrelevant to talk about the engineering or artistic quality of a language. > Engineers should think before they work. They should also *think* > before they post :-) Indeed. May your ears hear the wisdom of your mouth. :-) -- Richard Harter, Software Maintenance and Development Systems, Inc. Net address: jjmhome!smds!rh Phone: 508-369-7398 US Mail: SMDS Inc., PO Box 555, Concord MA 01742 This sentence no verb. This sentence short. This signature done.
ghm@ccadfa.adfa.oz.au (Geoff Miller) (05/20/91)
tsarver@andersen.uucp (Tom Sarver) writes: >Hey guys, >This thread is getting a little tiresome.... Actually I was finding it quite interesting! [...interesting references deleted 'cause I haven't read them yet...] >Whoever does software engineering is a craftsman with different freedoms >and constraints. No one can determine unequivocally that a piece of >software is "right" or "wrong." True. In fact, for almost any computing problem there is a potentially infinite number of solutions (most of which are so obviously sub-optimal that we never consciously consider them at all), but even when we come up with a good solution it is very hard to demonstrate that it is the "best" solution - not least because there are several ways to define "best". It is this lack of a clear single "right" solution which distinguishes computing from a science, but maybe emphasising the creative and "artistic" nature is not the way to go either. I'm reminded of the title of Dijkstra's book, however, and maybe we should just stick with that - A "Discipline" of Programming. Geoff Miller (ghm@cc.adfa.oz.au) Computer Centre, Australian Defence Force Academy
styri@cs.hw.ac.uk (Yu No Hoo) (05/20/91)
In article <2996@odin.cs.hw.ac.uk> I wrote: >How about comparing the software craftsman to the old stonemason. In article <19669@crdgw1.crd.ge.com> eaker@ukulele.crd.ge.com (Charles E Eaker) writes: >Take a look at Ken Follet's "Pillars of the Earth". It's a wonderful >novel set in the 12th century and contains an enormous amount of detail >about the craft of cathedral building in the absence of an engineering >profession. Has some great examples of how rules of thumb such as >"To make it stronger, make it thicker," literally fall down. Agree, nice book. But, don't make jokes about their rules of thumb. And, even in the absence of an engineering profession - some of these guys were really good engineers. And even engineering gives some freedom for some artistry, both of the esthetic and the innovative kind. I guess a problem with this discussion is that we forget that we may wear many 'hats' in our work. I don't view myself as an engineer when I'm writing a piece of code. Coding is a craft. However, I write my code to some design or specification that may be a product of engineering, and supervising the progress of construction may also be engineering. Constructing a pipeline may be engineering, welding pipes is not. Designing software should probably be compared to designing a building. There are elements of esthetics, there are elements of functionality and there is a limit on how much we are willing to pay. More important, one definition of the term architecture is "the art and science of designing and constructing buildings". Functionality and user friendliness aren't something added by some joiner at a later stage. Art and engineering may be orthogonal entities, but they aren't contratictory. ----------------------- Haakon Styri Dept. of Comp. Sci. ARPA: styri@cs.hw.ac.uk Heriot-Watt University X-400: C=gb;PRMD=uk.ac;O=hw;OU=cs;S=styri Edinburgh, Scotland
tsarver@andersen.uucp (Tom Sarver) (05/20/91)
In article <1343@grapevine.EBay.Sun.COM> chrisp@regenmeister.EBay.Sun.COM (Chris Prael) writes: >From article <1991May16.231300.13345@casbah.acns.nwu.edu>, by tsarver@andersen.uucp (Tom Sarver): > > [Deleted discussion on references versus experimentation.] > >> In _...Scientific Revolutions_, Kuhn describes a period called "pre- >> paradigm in which participants are attempting to model the results of >> emperical studies (formal and informal) into a paradigm. This paradigm >> enables them to discuss findings in a common arena of terms. The >> discipline matures when the paradigm is found to account for a large >> percentage of phenomena. The discipline then enters an "engineering" >> phase in which people use the results of the discipline to advance >> someone's external goals (society's, an evil genius', etc.) > >This is an interesting speculation, but it is historically inacurate, >hence bad science. If you read the history of most scientific >developments, particularly in physics, you will find that most of the >major advances were the result of significant engineering advances. >Major engineering advances, on the other hand, have come most often from >advances in materials (engineering, though we now call it "material >science", other engineering advances, or scientific advances). > The statement above is a one-paragraph summary of a *BOOK*! This book was written by an historian, and therefore, my summary stands. However, I did not rule out the fact that science and engineering can, and do, work together. In fact, the Shaw's article graphically shows how this occurs. The point of my posting is that software engineering hasn't really reached the "engineering" phase. We simply don't have well codified knowledge. > [Deleted some discussion of Einstein's training.] > >Chris Prael --Tom Sarver tsarver@andersen.com Andersen Consulting 100 S. Wacker Suite 900 Chicago, IL 60606
kambic@iccgcc.decnet.ab.com (George X. Kambic, Allen-Bradley Inc.) (05/21/91)
In article <1991May13.185411.7253@netcom.COM>, jls@netcom.COM (Jim Showalter) writes: [...] > Indeed, and the sad thing is that traditional methodologies completely ignore > this simple reality--the classic "waterfall" model of software development > assumes what I call a "top-down omniscient" process, which would work great > if we could just find some omniscient engineers. In reality, either feedback > is accomodated in an ad hoc manner during development (with consequent penalties > in terms of efficiency, since the process is not explicitly set up to plan > for such feedback) or, as is often the case, feedback is folded in during the > inappropriately named "maintenance" phase. [..good stuff omitted to focus on waterfall for the moment..] OK - next comment. IMHO all "life cycles" contain the waterfall model at their most microscopic level: one engineer, one problem, short time scale (minutes), good knowledge base, etc. All other life cycles are constructed of the waterfall + feedback with varied deliverables at different time scales. GXKambic standard disclaimer
jls@netcom.COM (Jim Showalter) (05/21/91)
>OK - next comment. IMHO all "life cycles" contain the waterfall model at >their most microscopic level: one engineer, one problem, short time scale >(minutes), good knowledge base, etc. All other life cycles are constructed of >the waterfall + feedback with varied deliverables at different time scales. No argument. The problem is just that so many lifecycle models generalize from the microscopic to the macroscopic level, and simply don't work right when applied to non-trivial problems. -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
G.Joly@cs.ucl.ac.uk (Gordon Joly) (05/21/91)
Chris Prael <chrisp@regenmeister.EBay.Sun.COM> writes > [...] > This is an interesting speculation, but it is historically inacurate, > hence bad science. If you read the history of most scientific > developments, particularly in physics, you will find that most of the > major advances were the result of significant engineering advances. > Major engineering advances, on the other hand, have come most often from > advances in materials (engineering, though we now call it "material > science", other engineering advances, or scientific advances). > > Most people studiously ignore the fact that Einstein's training was not > in a scientific topic. His training was in examining patent > applications, a non-academic form of engineering training. > > Chris Prael "Einstein's training" must have been a great hinderance to him. He basically re-wrote the rule book with both (Special and General) Relativity and the photo-electric effect. Galileo and others had to fight against the establishment; engineering is by definition established c.f. Mary Shaw's article, %A Mary Shaw %T Propects of an Engineering of Software Engineering %J IEEE Software %D November 1990 %V 7 %N 11 previously cited in this list. ____ Gordon Joly +44 71 387 7050 ext 3716 Internet: G.Joly@cs.ucl.ac.uk UUCP: ...!{uunet,ukc}!ucl-cs!G.Joly Computer Science, University College London, Gower Street, LONDON WC1E 6BT No more pork sausages!
kambic@iccgcc.decnet.ab.com (George X. Kambic, Allen-Bradley Inc.) (05/24/91)
In article <1991May16.203518.22420@xstor.com>, iverson@xstor.com (Tim Iverson) writes: > In article <36650010@hpopd.pwd.hp.com> daves@hpopd.pwd.hp.com (Dave Straker) writes: [...] > There is no confusion. If a programmer uses a methodology, he is an > engineer. If not, then he is an artist (or a hack :-). The difference is > that good engineering can be done by anyone that understands the > methodology, whereas good art can only be created by someone with talent > (i.e. innate understanding of both work and medium). Don't think so. Good engineering cannot be done by anyone who understands the methodology, unless you mean understanding to include applications knowledge, experience, understanding of the scientific method, and a knowledge of history, for a minimum. Secondly, good art (at least in some eyes) can be created by good engineers but this is probably because they understand their work and their medium. The F-4 is a work of art, done by engineers who knew these things. GXKambic standard disclaimer
chip@tct.com (Chip Salzenberg) (05/25/91)
According to kambic@iccgcc.decnet.ab.com (George X. Kambic):
>The F-4 is a work of art, done by engineers who knew these things.
The F-4?
Ha!
The F-4 is proof that with a couple of J-79s, a barn door can fly.
What was that you were saying about "good engineering" and "art"?
--
Chip Salzenberg at Teltronics/TCT <chip@tct.com>, <uunet!pdn!tct!chip>
perl -e 'sub do { print "extinct!\n"; } do do()'kambic@iccgcc.decnet.ab.com (George X. Kambic, Allen-Bradley Inc.) (06/06/91)
In article <283D7F7E.54A2@tct.com>, chip@tct.com (Chip Salzenberg) writes: > According to kambic@iccgcc.decnet.ab.com (George X. Kambic): >>The F-4 is a work of art, done by engineers who knew these things. > The F-4? > Ha! > The F-4 is proof that with a couple of J-79s, a barn door can fly. > What was that you were saying about "good engineering" and "art"? No change. The F-4 has had an over 30 year service life. It does not fly apart when flying. This somehow implies (at least to me) good engineering. Do you like it as art? I do. The old adage about "if it looks good, it will fly good" or something like that, applies here. Barn door? Old barn wood makes good art. GXKambic standard disclaimer