|
Paul Penfield, Jr.D. C. Jackson Professor of Electrical Engineering, Department of Electrical Engineering and Computer Science, MIT. Affiliated with the Microsystems Technology Laboratories. |
When I was Head of the MIT Department of Electrical Engineering and Computer Science (September 1, 1989 - January 15, 1999) most of my efforts went into running the department, which is the largest at MIT. Some non-routine projects I was involved with during that period are the following. This page represents the state of these projects as of January 15, 1999, when I gave up responsibility for them.
Current projects are described elsewhere.
The period of phasing in our new EECS Master of Engineering program is now complete. The 1992 MIT faculty vote which established the Master of Engineering degree mandated a review of new programs after five years. This review was done in 1998, and a report, dated October 30, 1998 was delivered to various MIT committees. On December 16, 1998 a presentation was made to the MIT Faculty meeting.
We find that about two-thirds of the department undergraduates stay for a fifth year and earn the Master of Engineering in Electrical Engineering and Computer Science.
This program breaks the normal pattern of education that prevails here and elsewhere.
All these aspects illustrate the fact that the traditional administrative procedures in place at MIT should not be expected to apply unchanged. It is necessary to examine all the procedures and make changes as needed. It is also necessary to make these changes known to faculty, students, and staff. Finally, unintended side effects of any decisions should be looked for.
The program was recently described at the Engineering Foundation national conference "Realizing the New Paradigm for Engineering Education," Baltimore, MD, June 3 - 6, 1998. Abstract (3684 bytes). Presentation (22,569 bytes). Text (30,443 bytes).
In Fall 1996 I appointed a small committee of department faculty to look at the doctoral program, and make recommendations as though they were designing a new program from scratch. The co-chairmen of this committee were Prof. Tomás Lozano-Pérez and Prof. Stephen D. Senturia. There were only two boundary conditions on the study:
In all other regards, the design of the program was up to the committee, as though we had no doctoral program in operation.
The study was commissioned not because the current doctoral program was not successful, but rather because it had been decades since the last thorough examination, and in the interim the world has changed significantly.
The committee chose to call themselves the DOctoral Clean Slate committee, or DOCS for short. They issued a report in November 1996 which recommended a program that, if implemented fully, will require several changes in the way the department runs the current program. I am now in the process of starting a discussion within the department which will lead to a consensus on which recommendations of the committee to adopt and which not to adopt. Then we will begin the implementation of the desired changes.
So far department reaction to the report has been generally favorable. One department faculty member even went to far as to accuse the chairmen of the DOCS committee of giving committees a good name!
The task of implementing the recommendation of the DOCS Committee was assigned to an implementation team headed by Professor Arvind. The Arvind committee produced its own report. Some of the ideas are being phased in already, but others require more extensive plans.
For a long time the department has been hampered by having its computer science faculty housed off campus, in rented facilities in Technology Square. The risk associated with this geographic isolation is that it is more difficult to establish and maintain joint projects between some on the EE side of the department and others on the CS side. An extreme risk (which, fortunately, has not been close to coming to pass) is that the department could split into two departments. In 1973 there was some feeling on the part of some computer-science faculty in favor of a separate department, but the department changed its name (from Electrical Engineering to Electrical Engineering and Computer Science) and a split was avoided. Recently there has been very little sentiment in favor of a split.
A decision was recently made to build the new CIIS Building on campus to house the people currently in Technology Square. I will be active in raising funds for this purpose, and in coordinating activities among the various people involved, including fund raisers, occupants, planners, and architects.
I was the Chair of an ad hoc faculty committee looking at the World Wide Web and other advanced technologies, and the potential offered by such technologies to the MIT educational process and to the future of MIT. For more details, refer to the committee's home page. The committee has now issued its final report, which is a hypertext document on the Web.
We are encouraging use of the Web for our normal subjects, and we are looking for a suitable opportunity to try an experiment in distance education.
EECS Great Educator Awards are made to fifth-year M.Eng. students who, by virtue of exhausting their years of eligibility for MIT's undergraduate financial aid, do not have support. The idea is very simple. Students who have the necessary self-confidence may take out a loan to finance their fifth year, and the department, through the Great Educator Award program, pays the interest due on that loan, thereby making it interest-free.
Each Great Educator Award is made in the name of a former member of the EECS faculty, a former "Great Educator." The student is given a written description of that person's career, style, teaching and research contributions, and impact on MIT and on the world. That way, today's students can better appreciate the legacy left by former department faculty and see themselves as part of a continuing tradition of excellence.
Great Educator Awards keep alive the memory of yesterday's best teachers to let today's best students become tomorrow's best engineers.
Currently Great Educator Awards are in place or are in the process of formation for the following former department faculty members:
I was asked to write a mission statement for the Department and for the School of Engineering. It turns out to be easier to write one for MIT as a whole. Such a statement, with general community backing, could be very helpful in avoiding misunderstandings about which units at MIT are helping to fulfill its mission, and which, although doing excellent work, are not directly relevant to the Institute's mission.
Such a statement, if anything other than completely bland, is bound to be controversial. Some people will take offense, or even feel threatened, if their unit's actions are not seen to be "central." Other people will be upset if their style of operation does not seem to be viewed as favorably as another style.
Perhaps such a statement will be too controversial to gain consensus support, and therefore too dangerous to be "officially" endorsed. Even if that is so, there is great benefit from an open discussion of these ideas within the MIT community, because it will let all parties understand where others stand. I hope to get comments on the current draft mission statement, and, once I am happy with it, publish it in the MIT Faculty Newsletter, as a way of stimulating discussion.
Another reason for needing a mission statement is that changes in the criteria by which our bachelor degree programs are accredited by ABET will require such a statement.
This project cannot be considered successful. Neither the specific statement nor its general ideas have been generally adopted, and there does not seem to be any real interest in pursuing these ideas. The only tangible outcome was a column in The Interface, and IEEE newsletter devoted to engineering education. Text.
Edgerton Hall, Room 34-101, seats 325 people. It is used for large classes and for seminars and lecture of various types. Televising events from this room has proven cumbersome in several ways, yet it is necessary because of the great interest in the events that are scheduled there. In the past the TV crew required access to the room an hour in advance to set up, and then during the event the equipment and personnel were very visible to the local audience, and blocked the aisles. In addition, to get adequate quality artificial lights were used, and these were distracting to the local audience and annoying to the speakers. The ambience was thus one of a studio production, rather than a seminar.
Through the generosity of Robert H. Rines and Morton Goulder, funds became available to install equipment in the room to solve these difficulties. During the summer of 1996 the room was equipped with three modern, highly sensitive cameras on remotely controlled gimbals. The only imposition on the speaker on behalf of the remote audience is having the speaker wear a wireless microphone.
To pick up questions from the audience, a fourth camera was mounted, again on remotely controlled gimbals, at the front of the auditorium, and seven directional microphones were mounted on the ceiling to cover different sections of the seating.
This system has been in use a few years and is considered to be very successful.
As Department Head I led the development of the EECS department Web pages, starting with our home page. This Web site was intended for maximum information content and minimal attention-grabbing design. It currently requires a redesign since many of the pages are long in the tooth, and some important content and resources are not currently available. I have been asked by the new Department Head to participate in this redesign, so this project continues to be one of my responsibilities.
Publishing on the Web was recognized to serve two purposes:
We planned to place all significant department documents and forms on the Web.
A side benefit of publication on the Web (or on any novel medium for that matter) is that one is forced to reformat the material and prepare it for a different context. A result, and one that we are already finding, is that some documents are no longer in optimal form, having failed to evolve in a way suitable for today's needs. Or perhaps the reality is that a document is serving a different role from that originally intended. Or perhaps the reformatting calls to our attention the fact that some other documents are needed.
I personally drove the development of our department's Web pages, and gradually developed tools which permitted department administrators to carry out the maintenance of many pages as a routine part of their jobs.
The department has a conference room named after Dugald C. Jackson, who served as department head from 1907 to 1935. In that room is Prof. Jackson's personal library, the books he relied on in his professional career. These books are not cataloged, nor are they arranged properly. A process needs to be established, in case some of these books are not represented in the MIT library system, to enable their access by scholars.
This room is a primary meeting room for department faculty and students. We have put here a collection of books written by department faculty over the years. An appeal that was made to department faculty to donate a copy of each of their books resulted in a large number of donations. A suitable display of these books, in more or less chronological order, lets all who come into the room appreciate the immense contributions to electrical engineering and to computer science made by members of the department.
During the 1996-97 academic year I served as President of the National Electrical Engineering Department Heads Association, NEEDHA.
As part of this office I was expected to write a column for each of three issues of The Interface, a newsletter distributed to members of the IEEE Education Society and the ASEE Electrical and Computer Engineering Division. I decided to write these columns on relatively important topics, rather than focus on the NEEDHA organization itself. The first of these, in the November, 1996 issue, was on faculty diversity. It made the point that the reason we want to have programs to promote faculty diversity is that a diverse faculty can do a better job at education, which after all is the primary mission of any academic department. It is time that we department heads take the debate about diversity and affirmative action out of the hands of the ideologues, politicians, and narrow-thinking alumni, and instead frame it as a matter of effective business practice. The second of the three columns, in the April, 1997 issue, was on the next major revolution in engineering education, and a novel way of describing it in terms of time constants. The third one dealt with mission statements for departments. These three are all posted on my publication list.
I have led the design and installation of the NEEDHA World Wide Web site, which includes over a dozen separate pages. These are mounted on a computer operated by onShore, a commercial Internet access provider located in Chicago, IL. (This is one of four Web sites that I am at least partially responsible for.)
One interesting project associated with the NEEDHA Web pages has been the development of an on-line Directory that is based on the printed directory that has been published by NEEDHA for its members for many years. Among the interesting features of this directory are
The plan from now on is to keep the on-line directory up to date continually, and to use its data once a year to prepare the printed directory, relying on the form-letter feature of a desktop publishing program.
In Fall 1998 a NEEDHA members e-mail list was put into operation. Messages sent to the alias members@needha.org get redirected to a list comprised of NEEDHA members (taken from the on-line directory) and others designated by the NEEDHA office staff to be on the list.
The design of this system was an interesting challenge. I wrote the following brief description of this activity for the December 1998 NEEDHA Newsletter, but it was not printed because there was no space.
|
For several years IEEE has maintained an e-mail list of EE department heads. This list was very useful to NEEDHA members, but it required some degree of effort on the part of the NEEDHA office staff to keep it up to date. Last year the NEEDHA Board decided we should maintain our own e-mail list, but do it in such a way that it would not require extra work. The idea was to use the NEEDHA on-line directory, which already contains each department head'e e-mail address. That directory is already kept up to date because of its benefit to NEEDHA members, and the e-mail list could be automatically derived from it. Sounds simple. In principle, it is, but let me tell you about some of the pitfalls we encountered. The first design decision was whether to compute the list every time it is needed, on the fly, or precompute it whenever the on-line directory gets updated. Our first approach was to precompute it, but after encountering a series of problems we changed our minds. In principle the decision should be based on how often each of those events happens. In practice, however, it doesn't much matter, for two reasons. First, it only takes about two seconds to calculate the list from the 301 directory entries. Second, it may surprise you to learn that the frequencies of these two types of events are about the same. In October 1998, there were 50 messages sent to the list and 54 updating events. We also had to accommodate those department heads who prefer not to be on the list, for whatever reason. We decided to make this option available by means of a checkbox on the directory-entry editing form. Thus anyone who wants to avoid being on the list can edit his or her department's entry and just tick this box. At first we wrote a little Perl script that was called whenever the data base was updated. There are actually two directory-maintenance programs that can change the data, so each had to call this script. The script looked at every entry, and got the e-mail address if present, but not if the "keep me off the list" box was checked or if the recipient was already on the list (to avoid duplicates). It worked fine, and the file it created was about 7KB in size. We tested the mailing program by sending to a small test list, and things worked fine. Then, on August 28 I sent a message announcing the system to both the new list and the old IEEE list, and waited for my own two copies to arrive. I waited, and waited, and waited. The IEEE list worked fine. The new list did not work at all. The problem turned out to be a little-known limitation in the Unix data-base manager, at least as implemented on our machine. It seems that any mail alias over 1024 bytes long is automatically, silently, ignored. So the next day I sent a message to the same list saying, "never mind." It was back to the drawing board. We tried a number of kludges. One approach was to have seven separate files, each small enough, and then have one alias that calls them. That seemed to be what the Unix manual recommended. However, what actually happens is that the mailer is smart enough to recognize that the same message is being sent to multiple recipients, so the first thing it does is put the entire mailing list together to check for duplicates. Next we tried sending the message to a companion (or to the same) machine, seven times, and then forwarding back to smaller lists. Again the mailers were smart enough to avoid sending the bodies of the messages multiple times, by first consolidating the addresses. We also tried having one alias call another in succession. Nothing worked. Ultimately we decided to calculate the list on demand, and then send the message 300 times to the mail queue, each aimed at a single address on the list. The mail queue is then processed every 30 minutes. The Perl script to do this was finished and the list put into action again on September 21. I sent out the same earlier message, with a note of apology for not getting it right the first time. In the design of the script we encountered such jolly Unix and/or Perl "features" as an undocumented limit on the size of standard input (4096 bytes). We ultimately got around all these limits and demonstrated that the system works well with attached files, and with files and text over 1 MB in size. We also carefully designed the system so it would not bomb out if a user address begins with a hyphen. The new approach allowed us to do easily two other things that were required. First, we needed an Add File with names to be put on the list, even though they are not department heads. These include the NEEDHA office staff, NEEDHA Board members who are no longer department heads, and others who have expressed interest. Second, we have to maintain a list of invalid addresses. With department heads and mail addresses changing frequently, it is inevitable that some addresses will be wrong. As it turned out, about 20 were wrong at the beginning, and it took some effort to update the directory. This effort also served to maintain the on-line directory, so it was well spent. A password-protected Web page was provided to the NEEDHA office staff for maintaining this list. With this page, the Add File and the list of omitted names can be changed. Names in the Omit File expire after 30 days so in case the incorrect name is not fixed by then the error messages will start to pop up again. There is another file which helps configure the system by defining the list steward (to whom notices of undelivered mail are sent, so that people using the list are not bothered by these), and a special test mode that disables the list but sends messages instead to another list for debugging and maintenance purposes. You may be interested in knowing how the list is doing. There are 301 directory entries, of which 289 contain department-head e-mail addresses. Two people have asked not be be on the list, and there is one duplicate (this is a single department that serves two universities and so has two entries). There are 12 names in the Add File, and at this time three in the Omit File (all due to expire within the next 30 days). This leaves 295 recipients. The list seems to be used about twice per working day, and over half of the messages are faculty hiring announcements (this may be seasonal). There is a FAQ page (http://www.needha.org/email-list.html) in case you have questions. We would be interested in hearing your ideas about how this e-mail list can be improved to increase its usefulness to NEEDHA. |
Accreditation of higher education engineering programs is done by ABET, the Accreditation Board for Engineering and Technology and, in the case of programs with the phrase "computer science" in the title, by CSAB, the Computer Science Accreditation Board. Recently ABET has decided to make a radical change in the criteria used for such accreditaion. The new ABET Engineering Criteria 2000 represent a challenge to engineering educators. To aid its members and the electrical-engineering education community more generally, NEEDHA, the National Electrical Engineering Department Heads Association, established a Committee on Accreditation Issues. I am serving as a member of that committee, and contributed in a minor way to a white paper intended to inform NEEDHA members about the issues.