Project Course in Web Services

I’ve just finished reading Phillip Greenspun’s experience report, Teaching Software Engineering, which details a project course in building Web Services. Even though I personally, hate the Web’s architecture (but that’s a rant for some other time), it still remains as THE most influentential and convenient place to showcase one’s work. It’s also convenient for shopping, learning, participating in niche communities, etc. The Web has real business value, and is therefore un-ignorable.

Based on his experience with the course, Greenspun had some nice quotes, which pertain to thought’s I’ve been building recently as I’ve been digging into the question: ‘What makes education valuable?’.

Building Real-World Skill

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.

For every project in 6.916 Classic, we insisted on having a client. This is a person who can describe desired capabilities for an information system but offers no hint as to how to build it. The best clients are people who are in fact passionate about some sort of Internet service and completely clueless about all matters technical. Good sources of clients are dotcom CEOs, MBA students, non-profit organization directors, and university administrators.

we invited alumni who were working as professional software engineers to return to campus on Tuesdays and Thursday evenings to coach students during the 6 hours of supervised laboratory time per week. There are perhaps 10 alumni out there for every current MIT undergraduate.

The best projects were ones with clients who had the wherewithal to extend and maintain the service after the course is over, possibly by hiring the students who built it.

A plethora of useful circumstances are brought into alignment: Students are challenged in the same underspecified way that they’d face in a real job. That challenge is met by performing fast, iterative development, ala XP or Agile. They get to interact with an actual customer: deriving project worth from satisifing the client, and building experience with client rejection and other realistic bumps. Finally, they get to forge connections in a business network, which can help them when entering the job market.

Student Learning

Software engineering is a craft and can only be learned by practice.

Our experience [with producing five complete internet service projects] contrasts with typical software engineering courses in which a student builds only one application (or a piece of one application) during the entire semester. Research on simple word association tasks has demonstrated that people who learned to perform quickly but not accurately would have remarkably good recall even months later and, with a bit of practice, could always be made to perform accurately. Whereas people who were slow but accurate forgot all of their skills within a month or two.

Just another example where Quantity trumps Quality. People learn by actually practicing and experimenting. They do not learn by listening to lectures. Learning can be reinforced by discussion and analysis, by questioning and tweaking.

Building a Portfolio

At the end of the semester, a student in 6.916 could look back upon four or five completed Internet services. The first ones that he or she built had been done for the problem sets. They won’t have been complex. They may not have been built to a very high standard of polish. But their existence enabled nearly all students to become fluent in the arts of designing a data model, specifying a page flow, and implementing the designed system in SQL and a procedural language.

At the end of the semester we drill into the students’ heads the cold hard facts of the world: nobody owes them attention. We have each student group prepare an overview page that is a single HTML document, with a few screen shots, that demonstrates the major functions of the Internet service that they’ve built. Visit http://philip.greenspun.com/seia/gallery/ to see these pages.

Finally, it has been fun to watch our students graduate and go onto the job market. During job interviews they are able to point their interviewer to the URL of the running Web service that they developed during 6.916. Oftentimes, the student-built service is more sophisticated and is running on a more reliable infrastructure than most of the Internet applications launched on the public Internet by the interviewer’s company!

This is where I’ll have to distinguish my school: The lessons are online, but the workshop let’s you build your Programmer’s Portfolio.

Reaching for the Sky

Universities have long taught theoretical methods for dealing with concurrency and transactions. The Internet raises new challenges in these areas. A dozen users may simultaneously ask for the same airline seat. Twenty responses to a discussion forum question may come in simultaneously. The radio or hardwired connection to a user may be interrupted halfway through an attempt to register at a site.

In the second problem set (“reservation system”), students built a collaborative conference room scheduling system. This raises the problem of concurrency in a natural manner. Every student can understand that you don’t want to book two people into a room at overlapping times.

Third, because all of the projects have a predictable shape we’ll be able to introduce distributed computing challenges merely by having students offer services to each other.

Students said that the “metadata” problem set was very valuable for speeding work on their projects. Students were asked to build a knowledge management system by writing a computer program to write all of the computer programs. I.e., we gave them a machine-readable language for representing the system capabilities and user experience and asked them to write a program to generate the SQL data model and then the scripts to support the user experience.

In the final exercise of the problem set, we ask the students to mark certain rooms as requiring fees. Users who wish to book those rooms must supply a credit card number. At MIT we hook up the servers to a live merchant account at CyberCash. Thus our better students will be able to open their credit card statements in the middle of the semester and discover a few dollars in charges made by their own Web server.

UPDATE: Greenspun also has a quick bullet list of all the lessons learned, and outline of the course’s structure.