Douglas T. Ross

From Wikiquote
Jump to navigation Jump to search

Douglas Taylor "Doug" Ross (December 21, 1929January 31, 2007) was an American computer scientist pioneer, and Chairman of SofTech, Inc. He is most famous for originating the term CAD for computer-aided design, and is considered to be the father of Automatically Programmed Tools (APT) a language to drive numerically controlled manufacturing.


  • The assertion that a problem unstated is a problem unsolved seem to have escaped many builders... All too often, design and implementation begins before the real needs and system functions are fully known. The results are skyrocketing costs, missed scheduled, waste and duplication, disgruntled users and endless series of patches and repairs euphemistically called "systems maintenance"
    • D.T. Ross and K.E. Schoman (1977) "Structured analysis for requirements definition" IEEE Transactions on Software Engineering. Vol 3. (1) p. 6-15; as cited in: G. Agyekum-Mensah et al. (2012) "Adaption of structured analysis design techniques methodology for construction project planning".
  • This report summarizes the activities of the M.I.T. Computer-Aided Design (CAD) Project from 1 December 1959 through 3 May 1967 in the development of a generalized 'system of software systems' for generating specialized problem-solving systems using high-level language techniques and advanced computer graphics. Known as the AED Approach (for Automated Engineering Design) the Project results are applicable not only to mechanical design, as an extension of earlier development of the APT System for numerical control, but to arbitrary scientific, engineering, management, and production systems as well.
  • There is a rigorous science, just waiting to be recognized and developed, which encompasses the whole of 'the software problem,' as defined, including the hardware, software, languages, devices, logic, data, knowledge, users, users, and effectiveness, etc. for end-users, providers, enablers, commissioners, and sponsors, alike.
    • D.T. Ross (1989) "Appendix B: Understanding: The Key to Software" in: Computer Science and Telecommunications Board, National Research Council Scaling Up: A Research Agenda for Software Engineering. p. 66 (cited on p. 3).

Computer-Aided Design: A Statement of Objectives (1960)[edit]

D.T. Ross et al. (1960) Computer-Aided Design: A Statement of Objectives.

  • The objective of the Computer-Aided Design Project is to evolve a machine systems which will permit the human designer and the computer to work together on creative design problems.
    • p. iii: Abstract.
  • From the computer application point of view the primary problem [of Computer-Aided Design] is not how to solve problems, but how to state them.
    • p. iii; Abstract.
  • It is very difficult to define what is meant by computer-aided design since the complete definition is, in fact, the sum and substance of the total project effort which has only begun. It is much easier to describe, what is not computer-aided design as we mean it.
    • p. 1.
  • Computer-aided design is not automatic design, although it must include many automatic design features. By automatic design we mean design procedures which are capable of being completely specified in a form which a computer can execute without human intervention.
    • p. 2.
  • Computer-aided design also is not automatic programming, although automatic programming techniques must necessarily play an important role in computer-aided design.
    • p. 2.
  • Automatic design has the computer do too much and the human do too little, whereas automatic programming has the human do too much and the computer do too little. Both techniques are important, but are not representative for what we wish to mean by computer-aided design.

Structured analysis (SA): A language for communicating ideas (1977)[edit]

D.T. Ross 1977 "Structured analysis (SA): A language for communicating ideas" in: IEEE Transactions on Software Engineering Vol. 3, No. 1, Jan 1977. p. 16-34.

Example of a structured analysis approach.
  • Structured analysis (SA) combines blueprint-like graphic language with the nouns and verbs of any other language to provide a hierarchic, top-down, gradual exposition of detail in the form of an SA model. The things and happenings of a subject are expressed in a data decomposition and an activity decomposition, both of which employ the same graphic building block, the SA box, to represent a part of a whole. SA arrows, representing input, output, control, and mechanism, express the relation of each part to the whole.
    • p. 16.
  • Neither Watt's steam engine nor Whitney's standardized parts really started the Industrial Revolution, although each has been awarded that claim, in the past. The real start was the awakening of scientific and technological thoughts during the Renaissance, with the idea that the lawful behavior of nature can be understood, analyzed, and manipulated to accomplish useful ends. That idea itself, alone, was not enough, however, for not until the creation and evolution of blueprints was it possible to express exactly how power and parts were to be combined for each specific task at hand.
    • p. 16.
  • Mechanical drawings and blueprints are not mere pictures, but a complete and rich language. In blueprint language, scientific, mathematical, and geometric formulations, notations, mensurations, and naming do not merely describe an object or process, they actually model it. Because of broad differences in subject, purpose, roles, and the needs of the people who use them, many forms of blueprint have evolved, but all rigorously present well structured information in understandable form.
    • p. 16.
  • There are certain basic, known principles about how people's minds go about the business of understanding, and communicating understanding by means of language, which have been known and used for many centuries. No matter how these principles are addressed, they always end up with hierarchic decomposition as being the heart of good storytelling. Perhaps the most relevant formulation is the familiar: "Tell 'em whatcha gonna tell'em. Tell 'em. Tell 'em whatcha told 'em." This is a pattern of communication almost as universal and well-entrenched as Newton's laws of motion.
    • p. 17.
  • The natural law of good communications takes the following, quite different, form in SA:
Everything worth saying
about anything worth saying something about
must be expressed in six or fewer pieces.
  • p. 18; Statement cited in: Peter Freeman, ‎Anthony I. Wasserman (1983), Tutorial on software design techniques. p. 98.
  • We never have any understanding of any subject matter except in terms of our own mental constructs of "things" and "happenings" of that subject matter.
    • p. 19.

An Interview with Douglas T. Ross (1984)[edit]

"An Interview with Douglas T. Ross" Conducted by William Aspray on 21 February 1984, Waltham, MA

  • I was sort of a hellraiser with a bunch of friends, most of whom were squeaking by with C's and D's while I was getting an A-average and should have been doing better. I did a lot of things on my own. I liked to make things with my hands. There was a lot of woodworking, model building, and model railroading. I collected stamps, and did various things in chemistry. I used to make things that exploded, and all that sort of thing. So I evidently got quite a good background in science. I always had a knack for that sort of thing. The hospital had a subscription to Scientific American and Science. So things came every week and I consumed them...
    • Response to the question: Did you outstrip the offerings of the school, say in the sciences and mathematics?
  • I realized after I'd been at MIT for a while that I had never even known the semantics of the word "engineering". You see, all my relatives and contacts were medical doctors or biology and chemistry professors. In fact, I'm almost the "black sheep" in the family for not being an MD or Ph.D. because everybody was doing that sort of thing. There was no contact at all with engineering. I didn't even know what the word meant...
    • p. 11; Response to the question Were there any engineering courses offered and did you take them?
  • With all this science and physics and so forth that I absorbed. I did have one early experience with engineering, however. When we got the Book of Knowledge, I found on one page a diagram for a short-wave radio. I thought it would be neat to try to make a shortwave radio, so I arranged with all the radio repairmen in the town that whenever they were going to junk a radio, they should set it aside and I would pick it up. I got all these old radios -- really classics now -- that I stripped. I had huge transformers and loudspeakers and huge condensers -- the whole works. Boxes full of this stuff. I didn't understand it. I didn't know a thing about it. I just liked to take things apart and learn how to solder. I discovered out of my collection of parts -- with the tuning condensers (with movable plates), the knobs, and all that stuff, that I had what seemed to be needed in this one page diagram of a shortwave receiver.
    • p. 11-12.
  • I just looked in the phone book, and called up the Executive Officer of the Servomechanisms Laboratory (Al Sise) and said, "I'm a math graduate student and would like a summer job. If you could find an electrical engineering student, I'm sure by the end of the summer we could make you an electronic calculator that would beat the pants off that little mechanical thing that Wiener has put together. Are you interested?"
    • p. 17.
  • A lot of people are not familiar with the fact that when Lincoln Lab grew out of the Project Whirlwind (which were just names to me at that point) for the purpose of looking into radar air defense -- processing radar signals with the computer and then using radio controls to defend with fighters and so forth -- Whirlwind had been originally designed as an aircraft simulator for individual airplanes.
    • p. 22.

An Interview with Douglas T. Ross (1989)[edit]

"An Interview with Douglas T. Ross" Conducted by Judy O'Neill on 1 November 1989, Cambridge, MA

  • The first paper I ever wrote was "Gestalt Programming" and that was in 1955. The whole idea there was to replace the laborious writing out of detailed programs and all those steps by having analyzed a problem area well enough so that you had what I later came to call a "systematized solution." Then you could compose different problems of this class by just plugging together pieces of program, and they would in turn be controlled by a pushbutton language. The user would make a number of discreet selections. It's just like nowadays it's done with menus, and when you had indicated all the pieces that you wanted to put together--by these mnemonic names and words for things associated with buttons, switches, with one meaning "period," essentially, for that sentence, you see--all these things would be brought together and that would be the man/machine, manual-intervention mode of problem-solving. I took over the term from studying Gestalt psychology, meaning that everything was brought together at once, as a unit, instead of this laborious step-by-step build-up.
    • p. 4.
  • The artificial intelligence people, the artificial intelligencia,... kept choosing little games to play, and little things that they could master, right? But my whole philosophy has always been give me a really tough problem that's just beyond the state-of-the-art, and give me a whole bunch of users beating on me to get it done. In other words, the real core of what being an engineer is.
    • p. 24-25.
  • The real core of what being an engineer is. You have a scientific basis, but when you don't have the science, you put in some bugger factors, some safety factors, and so forth and you get smart enough, and you get the job done anyhow, right? Economically, and as close to on time as you can make it. And if the customer is asking for something that's outlandish, give him what you can, and educate him back to what it is.
    • p. 25.

Retrospectives : The Early Years in Computer Graphics at at MIT, Lincoln Lab and Harvard (1989)[edit]

Douglas T. Ross (1989) in: J. Hurst (1989) Retrospectives : The Early Years in Computer Graphics at at MIT, Lincoln Lab and Harvard".

  • I introduced what I called "outside-in problem solving," which nowadays is called "top-clown." But I prefer outside-in because outside-in allows you to have many different viewpoints instead of a single top that you stupidly try to get to the bottom of, and things of that sort. Object oriented programming came out of that.
    • p. 25.
  • The APT and CAD Projects had one Air Force sponsorship, but it was actually a combination of about five or six projects, all going in parallel on both hardware and software matters, and I couldn't keep track of things, so I would take Polaroid pictures of the blackboard and then say what we had talked about into my dictating machine and my secretary would type it up.
    • p. 26.
  • A general theme for what I'm trying to convey and what actually drove me and my very industrious and creative project members over all these years, is... that there is much more to it than pictures. It has to be a picture language. There has to be meaning there, and the meaning is useful. You're trying to solve problems. So it really comes down to man machine problem solving . Better means of communication and expression is what always has driven our work.
    • p. 26.
  • Even though we started in the days when the equipment itself wasn't able to do very exciting visual things, we were always concentrating on this matter of communication and meaning.
    • p. 26.

Quotes about Douglas T. Ross[edit]

  • Douglas T. Ross, who began his career as a graduate student in math at MIT where he was quickly lured into computing, serving as head of the Computer Applications Group from 1952 to 1969, when he left MIT to form SofTech, Inc., which he served as president until 1975 and since then as chairman.
    He's made seminal contributions to several areas of computing, ranging from automatic programming of numerically controlled tools, the computer language APT, through Computer Aided Design, his Automated Engineering Design System, down to software engineering, the method of structured analysis design technique, which he puts generally under the heading of man machine collaboration.
    He's an old hand at historical gatherings, having reported on APT at the conference on the History of Programming Languages held in 1978, and more recently on the early development in the History of Personal Workstations in 1986.
  • As Head of the Computer Application Group at the MIT Electronic Systems Laboratory, Doug led the development of the Automatically Programmed Tool Language (APT), a special purpose programming language that became the world standard for programming computer-controlled machine tools. He then turned his attention to the development of a software engineering methodology and supporting tools. This led to the development while at MIT of the first software engineering language and supporting tools, the AED system. In 1969 Doug founded SofTech, Inc. where he continued to work on software engineering standards. While at SofTech, Doug conceived of SA, a graphic notation and methodology for system description. SA has been successfully applied worldwide as SofTechs Structured Analysis and Design Technique (SADT) or as the U.S. government standard IDEF0.
    • "Douglas T. Ross: Obituary". Boston Globe, 2007.
  • In his article “CAD: A Statement of Objectives”, published in. 1960, Ross, who was thirty years old then, defined not only the term CAD, but also the principles, goals and visions of Computer Aided Design. His ideas shaped all the further CAD development in the past 50 years.
    • Michael Abramovici (2007) "D.T. Ross Medall Award 2007".
  • For me, he has been an important pioneer in crucial areas throughout his career. Here are two examples:
    • In programming languages, the elaboration of new data structures, which became later known as records; cf. the plexes of the AED language in the fifties.
    • In large-scale system design, the systematic use of refinement into successive abstraction levels; cf. his well-known Structured Analysis and Design Technique (SADT) method in the sixties, and the company SofTech (a nice name) he founded.
Later, Doug became more and more interested in epistemological, philosophical and logic-related studies. It is possible his work in that direction became too pioneering or too advanced for his colleagues, including us. Who knows, the future may prove him right. At any rate, his reflections regularly made me think.

External links[edit]

Wikipedia has an article about: