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"
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 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.
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.
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.
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.
Computer-aided design also is not automatic programming, although automatic programming techniques must necessarily play an important role in computer-aided design.
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.
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 natural law of good communications takes the following, quite different, form in SA:
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...
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?"
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.
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.
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.
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.
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.
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.
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.