TITLE: An Unsuccessful Curriculum Proposal AUTHOR: Eugene Wallingford DATE: August 11, 2006 8:23 AM DESC: ----- BODY: Now that the issue has been resolved, I can finally write on a topic I mentioned three weeks ago, my department's proposal to create a new major in Software Engineering. This is one of those persistent "interruptions" this summer that really was an important task in its own right. It also reminds us all that academic politics are a non-trivial exercise. A couple of years ago, the faculty in my department decided to propose three new majors. One, bioinformatics, targeted an area of growing importance in which computing is an essential component. Graduate programs in bioinformatics were becoming common at this time, but few or no undergraduate programs existed. We figured that this major would attract a new audience of potential students and capitalize on the strong math and biology departments here. The other two proposals were extensions of the standard B.S. in Computer Science program we already offered: Software Engineering, and Networking and System Administration. These proposals targeted particular professional areas that our students pursue within our existing majors, giving them a little extra heft and their own identity. We figured that these majors would allow current CS students to choose a major that more directly matched their professional careers and hoped that they would attract students interested in these areas who might otherwise not attend our university. Such "targeted majors" are becoming more common throughout the country, and we hoped to be in the vanguard. Personally, I'm not a big fan of "superset majors" like Software Engineering and Networking, because I think even our most professionally-oriented students are best served with a broad CS major that prepares them for a diverse and dynamic discipline. But I do understand their appeal to students and thus their utility as marketing tools. Add to this reports such as Iowa's Information Technology Strategic Roadmap, which recommends focused majors as tools for developing the state's base of IT workers, and such majors become even more attractive to the university. At a time when our discipline is changing, such majors represent a reasonable effort to broaden and focus our reach at the same time. In order to create a new major at one of Iowa's three public universities, you must have it approved by the system-wide Board of Regents. Before a proposal reaches the Board level, though, it first must receive approval from the provosts at the three institutions. This is a reasonable mechanism which generally ensures that all of the universities know what the others are doing, helps identify opportunities for collaboration, and prevents unnecessary duplication in programs. Our bioinformatics and NaSA proposals were approved in the initial proposal cycle, but software engineering was not. One of our sister institutions raised objections to all three proposals, but the other gave us its blessing. As part of a compromise to overcome the objections, our administration withdrew the Software Engineering proposal from the table. This succeeded because, while the objecting school would have preferred that we not offer any of the new majors, its greatest objection was to the Software Engineering proposal. This objection ultimately came down to our use of the word 'engineering' in the title of a degree program. The other schools have Colleges of Engineering, but we do not. Engineers take use of the word 'engineering' quite seriously as a matter of professional honor. To them, engineering means something specific, and engineering education requires a specific set of courses in mathematics and the physical sciences, as well as specific experiences rooted in how professional engineers craft their trade. My university does not offer a traditional engineering program, so our engineering colleagues do not consider us capable of offering an engineering major. So we passed on our Software Engineering proposal and put our energies into launching the other two new majors. They've now been on the books for a year and have begun to attract majors. We've also experimented with professional marketing techniques to introducing bioinformatics to our target audiences. By the time I became department head, we had a new dean and a new provost, and our faculty really wanted to re-propose the Software Engineering major. The faculty did not feel that the original proposal had been dismissed on its merits, but rather for political reasons, and they wanted the chance to make their case that we be allowed to offer this new major, which so closely aligns with the professional goals of many of our students. So we set out to educate our new administration on the discipline and why our university should be offering degrees in software engineering. Once they were convinced, we took our case back to the council of provosts. Not too surprisingly, we encountered the same objection. Actually, we encountered several objections. Since the time of our initial proposal, the objecting school had proposed its own Software Engineering degree program. So now there were concerns about duplication of effort and resources. Those of you on university faculties surely know that duplication among state schools is a big issue these days. State funding isn't as plentiful as it used to be, and so unnecessary duplication is viewed as an unacceptable financial luxury. Another objection involved the fact that we did not intend to seek accreditation of our program by ABET, the standard accrediting agency for engineering programs. As a matter of professional standards, nearly all traditional engineering programs are accredited by ABET. Software engineering programs are a relatively recent phenomenon, as is their accreditation. Programs started within colleges of engineering do tend to seek accreditation, but not all do. A considerable number of undergraduate software engineering programs -- about a quarter of the thirty programs currently being offered in the U.S. -- lie outside of an engineering college and are much less likely ever to seek accreditation. This might be a concern for the established engineering disciplines, but I think it is less of an issue for software engineering. I'm not sure we know how to "engineer" large software all that reliably yet, and I'm not sure that we have a good sense of what all software engineers should know or be able to do. Projects such as SWEBOK are valuable efforts to catalog our current understanding, but what we really need is many more years building big systems and examining our practices along the way. This brings us back to the semantic issue that lies at the heart of the objections to our program proposal. Our engineering colleagues consider software engineering to be an engineering discipline like mechanical or electrical or civil engineering, and as such they think it should be treated like the traditional engineering programs. Whatever the professional assessment of engineering colleges regarding the use of the word "engineering", the term "software engineering" is widely used throughout the U.S. and the world in a broad sense, to describe the disciplined construction of software systems. Courses in software engineering are offered by many different academic institutions, including the majority of Computer Science departments these days. Graduates of computer science and information systems programs move immediately into positions with the title "software engineer" in many different kinds of companies. For our students, these employers ranges from traditional engineering companies to financial services companies such as insurance companies and banks. Many small, independent software developers consider themselves to be software engineers, though they would never consider becoming a licensed professional engineer. Standard use of the term "software engineering" does not indicate "engineering" in the sense understood by the engineering profession. Perhaps it should. Our colleges of engineering would prefer to define the term prescriptively, setting standards and ensuring that anyone who bears the title of engineer meet a set of common standards first. This is a noble aspiration. But my definition of the term is descriptive, in the sense of describing how it is used by people out in the world. In this descriptive sense, I think it is perfectly reasonable for my university to offer a Software Engineering degree. Alas, I am not the one to make this decision. Our sister institutions persisted in their objections to our proposal, and so again it failed. Had we changed the name of our program to Software Development or almost anything else without the word 'engineering' in it, we would probably have succeeded in having our program approved. Our faculty decided that to change the name of our program to something non-standard would defeat the purpose of offering a specialized degree in the discipline; it wouldn't match up with the expectations of students or the companies that hire them. Besides, the non-standard name feels distinctly sub-standard, as if we aren't capable of offering a degree in the discipline that folks have come to regard as standard in industry. Sadly, I fear that there may have been an element of this thinking in our sister institution's objection to our proposal. They think us worthy of offering an "applied computer science" program in something called software development, but not worthy of awarding degrees in Software Engineering. I work at a so-called teaching university. While most of our faculty is engaged in research and other scholarly activity, basic research is not our mission; producing well-educated citizens is. A computer science program at a school such as mine blends a solid core of empirical CS with what amounts to professional education, not all that different from the pre-professional programs we offer students interested in pursuing law degrees and medical degrees. For most of our CS students, computer science is a professional degree, and software engineering is one of their professions of choice. One of our goals is to produce broadly educated practitioners in a discipline that changes rapidly, while at the same time changing the world in which the practitioners practice. Ultimately, I think that our position on who should be teaching software engineering will be proven right by history. While I am not a big fan of the metaphor, software engineering as a discipline is much bigger than colleges of engineering conceive it, and more and more schools will teach it. In the meantime, we will continue on with what we have -- a B.S. program in Computer Science, with a Software Engineering emphasis -- and prepare students to enter the world ready to develop software, including the largest of systems, whatever that activity may be like in the future. I sit hear now wondering what software engineering programs in colleges of engineering and think about agile approaches to software development. Maybe we are lucky not to be constrained by the straightjacket of expectations that accompany the programs in established engineering disciplines. We are still learning how to build software, and we can fold our learning into our courses and curricula much faster when we don't have to worry about a set of restrictions based in other engineering disciplines. Anyway, for those of you who think that "office politics" in the "real world" make life worse than it is in the ivory tower, this little story only scratches the surface of what university politics are like. That's a whole other story... -----