Before plunging into these issues, let's take a step back and reflect on the rationale for teaching this material at all.
Once we've taught students how to build Internet applications, it is gratifying to observe their enormous potential. A computer science graduate in 1980 was, by his or her efforts alone, able to reach only a handful of users. Thanks to the ubiquitous Internet, a computer science student today is able to write a program that hundreds of thousands of people will use before that student ever graduates. One of our student teams, for example, built a photo sharing service launched to the users of photo.net. Through March 2003, the software built by the students is holding more than 500,000 photographs on behalf of roughly 33,000 users.
Scientists measure their results against nature. Engineers measure their results against human needs. Programmers ... don't measure their results. As a final overarching deep principle, we need to teach students to measure their results against the end-user experience. Anyone can build an Internet application. The applications that are successful and have impact are those whose data model and page flow permit the users to accomplish their tasks with a minimum of time and confusion.
We'd like our students to be able to take vague and ambitious specifications and turn them into a system design that can be built and launched within a few months, with the most important-to-users and easy-to-develop features built first and the difficult bells and whistles deferred to a second version. We'd like our students to know how to test prototypes with end-users and refine their application design once or twice within even a three-month project. We'd like our students to be able to think on their feet and speak up with constructive criticism at design reviews.
These desires translate into some aspects of how we use this textbook at MIT: real clients so that students are exposed to the vagueness and confusion of real-world problems; user testing built into the homework problems; "lecture" time primarily devoted to student-student interaction with the instructors moderating the discussion.
Students in a traditional computer science curriculum will
Survey courses have been similarly successful on the electrical engineering side of our department. In the good old days, MIT offered 6.01, a linear networks course. Students learned RLC networks in detail. But they forgot why they'd wanted to major in electrical engineering. Today the first hardware course is 6.002, where students play with op-amps before learning about the transistor!
One of the most celebrated courses at MIT is the Aeronautics and Astronautics department's Unified Engineering. Here is the first semester's description from the course catalog:
Presents the principles and methods of engineering, as well as their interrelationships and applications, through lectures, recitations, design problems, and labs. Disciplines introduced include: statics, materials and structures, dynamics, fluid dynamics, thermodynamics, materials, propulsion, signal and system analysis, and circuits. Topics: mechanics of solids and fluids; statics and dynamics for bodies systems and networks; conservation of mass and momentum; properties of solids and fluids; temperature, conservation of energy; stability and response of static and dynamic systems. Applications include particle and rigid body dynamics; stress and deformations in truss members; airfoils and nozzles in high-speed flow; passive and active circuits. Laboratory exposure to empirical methods in engineering; illustration of principles and practice. Design of typical aircraft or spacecraft elements.Note that this is all presented in one semester, albeit with double the standard credit hours. For almost every topic in the course description, MIT has one or more full-semester courses exclusively devoted to that topic.
Experiences like these led us to develop Software Engineering for Internet Applications and the corresponding survey course in building computer systems for collaboration.
If you agree with the student to work within the framework of Internet Application Workbook the project has enough structure that risk is minimized yet enough flexibility that the student's creativity can flower. For example, using this book means that the student will be using a relational database management system. All of the code that you have to review will be in SQL. Yet the student is free to experiment with the operating system and HTML glue environment of his or her choice. The student will be building an Internet application that has user registration, content management, a discussion forum, and full-text search, and a combination of the book and the public Internet provide a good context for evaluating the student's achievement in these areas. Yet almost any client will put before the student idiosyncratic challenges that should give the student an opportunity to build something unusual.
We consider Mozart to have been creative although he did not develop new musical forms, relying instead on the structure laid down by Haydn. A student will accomplish more if he or she can spend the first months of a project working rather than figuring out what field in which to work, roughly what the scope of the project should be, what tools to choose from an unlimited palette, etc.
It would be nice to include a section on high-level formal specification of page flow and data model. Unfortunately as of 2003 there are no tools available for this that compile into standard executable languages such as SQL and Java. A quick glance at Unified Modeling Language (UML) might make one think that this is a useful nod in the direction of formal specification of Internet applications. Unfortunately UML cannot be compiled into a working system nor can it be verified against a system built in executable languages such as SQL and Java. Even if students mastered the 150 primitives of UML, the only thing that they would learn is that people in the IT industry can get paid high salaries despite never have learned to write clear English prose. Object Role Modeling (ORM), however, is a high-level formal specification language that looks promising for automatic code generation in the coming years.
Juniors and seniors might have had a summer jobs working with Oracle and PHP on Debian Linux or with Microsoft .NET and SQL Server. They will probably be most productive if they can continue using their familiar tools. Furthermore having a variety of tools in use during the semester provides all the students with an opportunity to learn a little bit about other development styles. The main risk to having students choose their tools is that some get sucked in by software vendor hype and elect to use, for example, three-tiered architectures and application servers. At MIT the students have three weeks before the start of the semester in which to install their chosen tools. All of the MIT students who decided to go the application server route were unable to get their systems up and running in time to do the Basics problem set and hence were forced to drop the class.
For sophomores it is less likely that students will have extensive development experience with a particular set of tools and the risk of a student choosing an inappropriate set of tools is increased. It may be best to standardize on one set of tools so that everyone in the class is using the same systems.
Universities spend hundreds of millions of dollars on dormitories so that students can drink beer together but are seemingly reluctant to spend a dime on shared workspaces for students. This is a shame because for learning most technical material it is much more effective for students to work together and live separately. A student working in a common laboratory with TAs and fellow students nearby won't get stuck on something simple, such as "how do I launch SQL*Plus?". If you can possibly arrange a room with a bunch of desks and PCs and make that the center of your class, this will be an enormous help to less experienced students.
At a minimum the meeting room must have one Web browser connected to a video projector. Ideally the room will additionally have extra Web browsers and keyboards distributed around the room, one for every 3-6 students, and blackboards or whiteboards for collaborative work by small teams.
Here is a sample schedule, the goal of which is to drive the student projects to public launch as quickly as possible:
[Giving students one week to do the Basics problem set seemed harsh to us and hence we decided one term to give them two weeks to do it. Rather than spreading the work out, the result was that most students did nothing until two or three days before the due date and ended up staying up all night.]
Another good question asks the students to visit a public Internet application, try it out, and write a critique of the user experience. In our exam we include the following admonition: "Your critique should be clear concerning what is wrong with the current system. Your critique should be explicit about what to change, such that a junior programmer could implement your improvements without depending on his or her own taste and judgement."
You might also want to ask the students to propose and justify a hardware and software architecture to handle a specific service and user load.
Note that all of these questions are sufficiently open-ended to lead to interesting classroom discussion. Note further that these exams must be graded by someone experienced with software engineering and data modeling.
What can your students offer real-world clients? In some cases a student team will build a launchable, documented, maintainable, high-performance system that the client can run for years. This happy result, however, is not necessary in order for a client to get value from participating in a course based on this textbook. Oftentimes working with a student team will enable a client to make decisions and formulate precise specifications. Most people are unable to make good decisions about information systems without seeing a prototype. We don't promise clients that their student team will solve their problem but we do promise clients that the experience will clarify their goals and, whatever else, will be over in 3.5 months.
Working groups within your own university can be a good source of clients. Groups that need to work with off-campus people, such as alumni, parents, or colleagues at other institutions, are especially logical candidates for online community support. Non-profit organizations can also be good sources of projects because they are usually much more patient than for-profit corporations and can afford to (a) wait for your semester to start, and (b) start over if necessary at the end of your semester in the event that the student team does not produce a launchable system. For-profit organizations can provide well-organized and highly motivated clients. Cash-starved startups and small neglected departments within larger companies may both be attracted to working with a student team. With any potential client, however, try to make sure that they have enough resources to gather content and users.
A bit of diversity among the client projects is nice but at their cores all of the client projects should be online communities. At the very least a project needs to have a discussion forum where User A can ask a question that User B will answer. Much of the value in this course comes from student teams comparing their differing approaches to the similar challenges of user registration, content management, and discussion support. If a client wants a 100-percent voice interface their team won't be able to learn from other teams very effectively nor will other teams building primarily Web browser sites be able to learn from the voice-browser-only team. If a client says "I want an online store", just respond "no". If a client says "I want an online store where the customers talk to each other," respond with "Okay, but the students aren't going to build the checkout pages until the end of the term and you'll have to offer them summer jobs if you want ecommerce admin pages."
Here are some criteria for selecting among clients:
This problem is not too severe for teaching Physics 101. The school pays one instructor and fills a room with 300 tuition-paying students. But teaching software engineering effectively requires that students be given an apprenticeship. No school will want to pay the army of instructors that would represent an optimum-sized teaching staff for a software engineering project course like this one. Even if a school had infinite money, professors and graduate students are probably the wrong people for the job. How much experience does the average academic computer scientist have in comparing a collection of software source code to a statement of user requirements and suggesting improvements?
We can solve the staffing and expertise problems in one stroke by bringing in alumni volunteers. A typical school has 10 or 20 times as many alumni as current students. If students are broken up into teams of 3 and each volunteer can assist two teams, we only need to convince approximately one percent of our alumni to volunteer each semester. As working software engineers, our graduates will likely do a much better job of assisting students than a fresh graduate student would and perhaps even a better job in some areas than a seasoned professor.
A course based on Software Engineering for Internet Applications is uniquely amenable to alumni mentoring because all of the students' work is accessible from any Web browser anywhere on the Internet. Between the plans and the /doc directory and the mandated "View Source" links at the bottom of every student-authored page, an alumnus 3000 miles away ought to be able to contribute almost as effectively as someone who is willing to come down to campus two nights per week.
In teaching with Software Engineering for Internet Applications you have a natural opportunity to separate evaluation from teaching. The quality of the user experience and solution engineered by a team is best evaluated by their client and the end-users. If the client responds to the questionnaire in Exercise 3 of the Planning Redux chapter by saying "Our team has solved all of our problems and we love working with them", what does your opinion matter? Similarly if a usability study shows that test users are able to accomplish tasks quickly and reliably, what does your opinion of the page flow matter? During most of this course we try to act as coaches to help our students achieve high performance as perceived by their clients and end-users. We use every opportunity to arrange for students to get real-world feedback rather than letter grades from us.
The principal area where we must retain the role of evaluator is in looking at a team's documentation. The main question here is "How easy would it be for a new team of programmers, with access only to what is in the /doc directory on a team's server, to take over the project?"