|
Software Engineering for Web Applications (6.916)part of Teaching by Philip Greenspun |
This course gives students the following skills:
At most colleges today, there is no way to learn all of these skills via the current curriculum. Even at schools where there are a lot of practical classes, the student would have to sit through three semesters before being able to serve a single page: Unix, C/C++, database, relational database management systems and SQL, object-oriented design, networking protocols, Internet protocols.
This course gives a student everything that he or she really needs to know. Some of the stuff is deep. For example, a Web server is an object. It has internal state, whose persistence is typically achieved via a relational database management system (e.g., Oracle). The methods are the URLs and the arguments to those methods are the form variables on the pages that target those URLs. Engineer will have to design future Web services so that their methods can be invoked by other services across the public Internet. Some of the stuff is shallow. The student needs to learn how to use Emacs, that typing "sqlplus" into the Unix shell is a way to connect to Oracle, that HTTP mandates headers separated by CRLF, then two CRLFs, then the page content.
By the end of this 13-week course at MIT, all of the students have built Web applications that compete with the best commercial Web services (but without the ugly banner ads). See arfdigita.org for an example.
In the Good Old Days our students would graduate and go to work for a large company where they would be a junior programmer. They'd spend five years learning to become an engineer from the experienced folks in their large organization. At age 28, they would begin to take on the role of senior developer or system architect. In the current world, however, a top MIT CS graduate will go right into a venture capital-backed .com startup as the Chief Technology Officer or senior developer. Our graduate will have to translate business requirements into technology decisions and won't be able to ask advice from more experienced people in their organization.
So the question is "Do we want to give MIT master's degrees in computer science, from the School of Engineering, to people who do not have the foggiest idea of how to engineer the kind of information systems that society wishes to build?" My answer is "No!" and "Here's a course that will at least familiarize students with the major challenges that they'll confront in the next 20 years of their careers and some ideas and technology that can be applied to meeting those challenges."
This is a senior-level class at MIT where we expect the average student
to be working on a bachelor's or master's degree in computer science, to
have taken our introduction to computer science (6.001), to have taken
our core software engineering class (6.170), and to have done at least
some programming during summer jobs.
That said, the class does not require any knowledge of particular
computer languages or systems. I.e., the students will learn enough
about the required tools as the course progresses.
This course is designed for easy adoption by other universities. We
provide the following materials online for free:
This course was developed by Hal Abelson (hal@mit.edu), Michael Dertouzos
(mld@lcs.mit.edu), and Philip Greenspun (philg@mit.edu).
For the lectures, you'll want a room with a good Internet connection and video projector so that all the students can see one Web browser.
Most of the work and learning happens during the problem sets. Ideally, the teaching assistants should be experienced software developers, e.g., volunteers from industry. The TAs and students sit side-by-side at a terminal and discuss approaches to a problem. This is the only way that we know of to teach students to build tasteful maintainable code.
If you have advanced students and a lot of TA resources, try to get
through the problem sets early in the semester and then let students
build projects in teams of two or three. We did this at MIT the first
time that we taught 6.916. It worked pretty well except that the
students weren't educated to a very uniform standard. The ones who were
strong programmers coming in were strong programmers going out; weak
programmers only got a bit better. The students who worked on good
project ideas with helpful clients did great work and learned a lot;
students saddled with weak project ideas or indifferent clients were
frustrated and didn't get much out of the project.
Here are some options: