Software Engineers

"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."

"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""

"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."

"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."

"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."

"For me, he has been an important pioneer in crucial areas throughout his career. Here are two examples:"

"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."

"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."

"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."

"As Head of the Computer Application Group at the MIT Electronic Systems Laboratory, Doug led the development of the (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 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 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 (SADT) or as the U.S. government standard ."

"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."

"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."

"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. came out of that."

"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."

"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?""

"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."

"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."

"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..."

"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."

"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..."

"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."

"The natural law of good communications takes the following, quite different, form in SA:"

"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."

"Graphical design notations have been with us for a while... their primary value is in communication and understanding. A good diagram can often help communicate ideas about design, particularly when you want to avoid a lot of details. Diagrams can also help you understand either a software system or a business process. As part of a team trying to figure out something, diagrams both help to understand and communicate that understanding throughout a team. Although they aren't, at least yet, a replacement for textual programming languages, they are a helpful assistant... Of these graphical notations, the UML's importance comes from its wide use and standardization within the OO development community."

"Comprehensiveness is the enemy of comprehensibility"

"The key books about object-oriented graphical modeling languages appeared between 1988 and 1992. Leading figures included Grady Booch [Booch,OOAD]; Peter Coad [Coad, OOA], [Coad, OOD]; Ivar Jacobson (Objectory) [Jacobson, OOSE]; Jim Odell [Odell]; Jim Rumbaugh (OMT) [Rumbaugh, insights], [Rumbaugh, OMT]; Sally Shlaer and Steve Mellor [Shlaer and Mellor, data], [Shlaer and Mellor, states] ; and Rebecca Wirfs-Brock (Responsibility Driven Design) [Wirfs-Brock]."

"Often you'll see the same three or four data items together in lots of places: fields in a couple of classes, parameters in many method signatures. Bunches of data that hang around together really ought to be made into their own objects."

"When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous."

"Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing the observable behavior of the software. To refactor (verb): to restructure software by applying a series of refactorings without changing the observable behavior of the software."

"When you find you have to add a feature to a program, and the program's code is not structured in a convenient way to add the feature, first refactor the program to make it easy to add the feature, then add the feature."

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."

"The second problem [with using UML for the purposes of this book] is that the Unified Modeling Language concentrates on implementation modeling rather than conceptual modeling"

"The key is to test the areas that you are most worried about going wrong. That way you get the most benefit for your testing effort. It is better to write and run incomplete tests than not to run complete tests"

"Modeling Principle: Models are not right or wrong; they are more or less useful."

"It is commonly said that a pattern, however it is written, has four essential parts: a statement of the context where the pattern is useful, the problem that the pattern addresses, the forces that play in forming a solution, and the solution that resolves those forces. … it supports the definition of a pattern as "a solution to a problem in a context", a definition that [unfortunately] fixes the bounds of the pattern to a single problem-solution pair"

"Often designers do complicated things that improve the capacity on a particular hardware platform when it might actually be cheaper to buy more hardware."

"Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a 'refactoring') does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it's less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring."

"Steve Mellor and I independently came up with a characterization of the three modes in which people use the UML: sketch, blueprint, and programming language. By far the most common of the three, at least to my biased eye, is UML as a sketch. In this usage, developers use the UML to help communicate some aspects of a system. As with blueprints, you can use sketches in a forward-engineering or reverse-engineering direction. Forward engineering draws a UML diagram before you write code, while reverse engineering builds a UML diagram from the existing code in order to help understand it."

"One of the things I've been trying to do is look for simpler or rules underpinning good or bad design. I think one of the most valuable rules is to avoid duplication. "Once and only once" is the Extreme Programming phrase."

"Transparency is valuable, but while many things can be made transparent in distributed objects, performance isn't usually one of them."

"The definition I use for a pattern is an idea that has been useful in one practical context and will probably be useful in others"

"People also underestimate the time they spend debugging. They underestimate how much time they can spend chasing a long bug. With testing, I know straight away when I added a bug. That lets me fix the bug immediately before it can crawl off and hide. There are few things more frustrating or time-wasting than debugging. Wouldn't it be a hell of a lot quicker if we just didn't create the bugs in the first place?"

"[Object-oriented analysis is] the challenge of understanding the problem domain and then the system's responsibilities in that light."

"To us, analysis is the study of a problem domain, leading to a specification of externally observable behavior; a complete, consistent, and feasible statement of what is needed; a coverage of both functional and quantified operational characteristics (e.g. reliability, availability, performance)."

"OOA - Object-Oriented Analysis - is based upon concepts that we first learned in kindergarten: objects and attributes, wholes and parts, classes and members."

"Elements (lines of code) in a coincidentally-cohesive module have no relationship. Typically occurs as the result of modularizing existing code, to separate out redundant code."

"Designed as a companion volume to the acclaimed Object-Oriented Analysis, this book focuses on the middle part of the software lifecycle: the activity of design. It shows readers how to apply object-oriented design, and how to tailor and expand the method to suit specific organization and project needs. Readers will explore the major issues in OOD; the role of OOD in the systems lifecycle; how to use graphical notation; strategies for creating design; and hints for evaluating the efficiency of a design created with OOD. For software engineers and other users undertaking real-world systems development projects and designing overall software architecture for systems will find this reference approach to improving systems design indispensable."

"A system composed of 100,000 lines of C++ is not be sneezed at, but we don't have that much trouble developing 100,000 lines of COBOL today. The real test of OOP will come when systems of 1 to 10 million lines of code are developed."

"Subject. A Subject is a mechanism for guiding a reader (analyst, problem domain expert, manager, client) through a large, complex model. Subjects are also helpful for organizing work packages on larger projects, based upon initial OOA investigations."