Monday, October 31, 2011

Retrospective

Phillip has very kindly posted a retrospective of all the things they learned after teaching SEIA for 4 semesters. I think it is important to understand what worked and what did not before attempting to design my own course.

There are two strategies to teach software engineering. It can be taught as a survey course, where we expose students to the entire engineering lifecycle and a lot of concepts. The hope is that the students will understand enough to be able to start working on a actual project, and then learn the ropes over the next 6 - 10 years. Another approach is to teach each individual part of the software engineering process in depth as a separate course. I am not sure if the latter approach will work well. I think software is fun when we are actually writing code. That is also the way in which most learning happens. I can say this from personal experience. If we taught every aspect of software engineering separately and in depth, then there is a chance that the student would forget the concepts when they actually have to use them. For all these reasons, I personally prefer the survey course approach. Evidence also seems to support my theory. At MIT EE students were earlier taught a course in which they learned networks in great detail. Even though students might become experts in that topic, at the end of the semester, they forgot why they wanted to learn EE. That is not a very encouraging state of mind to be in. Similarly, one of the most popular courses at MIT is the 'unified engineering' course offered by their aeronautical department.

What are the concepts that we want to teach the students ?
  • object-oriented design (modularization) where each object is a Web service (distributed computing)
  • about concurrency and transactions
  • how to build a stateful user experience on top of stateless protocols
  • about the relational database management system
  • basics of usability
  • basics of security
MIT focuses on teaching students principles rather than skills. The students learn the skills while applying the principles.

Next Phillip talks about how the classic 6.916 course was conducted. The students had done one course on software engineering, so they all had decent debugging skills. Time wise, this course consisted of 3 hours of classroom time, and 6 hours of supervised laboratory time. Besides this I am sure the students would have had to spend at least 1 hour doing research on their own. So this is approximately a 10 hour / week course for MIT students.

Quoting:



The fundamental characteristics of 6.916 Classic were the following:
  • problem sets provided the core knowledge
  • teaching assistants, oftentimes alumni, worked side-by-side with students in a supervised twice weekly lab to help with design issues and questions of taste
  • projects ran the entire length of term, starting with application design and ending with intense software development
  • by the end of the semester, each student had built four or five database-backed Internet applications



Using this format, by the end of the semester, a student would have build about 4 - 5 database backed Internet applications.

Quoting Phillip: There is research which seems to suggest that people do a lot of things in a course, but not very accurately, have better recall than students who do a few things but very accurately. My own experience agrees with this theory. This theory presents yet another argument for building survey courses.

The course has various problem sets which expose a student incrementally to new concepts in building web based applications. The problem sets are followed by an actual project with an actual client. Even though an actual project with a client is a great idea (in theory), in practice it has a lot of flaws. An actual client may be finicky and change their mind often about what they want. This is not good for a college course. I am more in favor of allowing the student to build a project of their choice, or maybe to do away with this stage totally, and let them simply start working in the real world and make their web application after working on the problem sets in the course.

At this point of time, I am convinced that a survey course with problem sets which will expose students incrementally to new concepts is the right way to design a course in building applications for the Internet. Now the next challenge is to create the problem sets. I think here is where my course is going to differ from MIT's 6.171

Creating a Software Engineering for Internet Applications course

Some time back I came across an excellent course called Software Engineering for Internet Applications. The course is taught by Phillip Greenspun at MIT, and has also been replicated by several other universities.

From some time, I have been thinking of creating an Applied Course on Internet Applications on diycomputerscience.com. I wanted it to be a course which would teach the most important concepts of Internet applications like understanding the HTTP protocol, web servers, databases, concurrency, scalability, security, usability, etc in a hands on approach.

The SEIA course provides a perfect guideline for such a course. I will probably make a few changes to the SEIA course, but my course will probably re-use a large part of the SEIA structure, but will probably have different problem sets.