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
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2006-07.html#e2006-07-21T17_15_09.htm">
   three weeks ago</A>,
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
<A HREF="http://www.iowalifechanging.com/studies.html">
   Information Technology Strategic Roadmap</A>,
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
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2006-01.html#e2006-01-20T12_25_18.htm">
   professional marketing techniques</A>
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
<A HREF="http://www.abet.org/">
   ABET</A>,
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
<A HREF="http://www.swebok.org/">
   SWEBOK</A>
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
<STRONG>sub-</STRONG>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...
-----