Friday, May 25, 2007

Learning by Doing Part 3

Great comments on Learning by Doing Part 2, thanks! Since writing the earlier posts, I realized that the term "topic" can be confusing, so I'll use instead "subject", which also allows me to discuss more easily the discussion between these ideas and traditional programs. Here are some tentative answers to earlier comments and to questions I came up with since:
  • Sample project: It's easiest to use one of my own research areas, biomedical information access. We have been working on systems for integrating biomedical text with databases that describe biomedical text. What we have built so far only scratches the surface of what would be possible with enough effort over a few years. We have had successful experience with undergraduates working on the project for independent studies and summer research experience. A project like this has many opportunities for learning standard subjects: object-oriented programming, data structures and algorithms, software engineering, databases, networking, machine learning, distributed systems, user interface design, basic statistics and experimental methods, as well as basic mathematical subjects like formal language theory, linear algebra, probability, and optimization. By carefully factoring projects and subjects, it would be possible to use the same subject module in different projects, and ensure that all students have to cover a broad set of subjects in their work. Think of the subjects as the books that you would have to consult when working successfully on your projects.
  • Projects in current Penn programs: I totally agree that we should extend senior project down into the junior and sophomore years. Faculty have been discussing this, but we haven't worked out the full model yet. This discussion may help. There might be an incremental path to learning by doing by increasing project-oriented work and short courses, and reducing standard lecture courses. Another possibility is to start small with a special program with limited enrollment to allow developing and debugging the proposal. Incidentally, I think it would be totally possible to create an ABET-acredited computer science learning-by-doing major, because what ABET cares about is about subject and skill coverage, not particular course structure, as we found out when going through the accreditation process last year.
  • Too much work; Having designed and redesigned a major freshman class over the last five years, I can't imagine that anything could be more work than that... There would be more interactive, event-driven work, but we would give fewer lectures, and we would not have to create and grade assignments, which is a major part of traditional course management. Teaching-by-doing is already what we do with graduate students. We would be bringing teaching and research much closer together at all levels, which would make teaching more creative and enjoyable, and improve research output. The NSF would love it for those reasons. I'm also pretty aware of the complexities of academic finances, course units, and faculty workload. I made some rough calculations while exercising at the gym (you need to use that time well...) I concluded that there isn't a huge order-of-magnitude mismatch between current faculty resources and the demands of a learning-by-doing program. Of course, it would require extra work to set up, but so does any significant change in the curriculum.
  • Is it too hard to do with freshmen: Maybe, but Michael Kearns has had great success with in-class activities and projects that have led to major publications in his Networked Life class. In our freshman introduction to programming, we have successfully used open-ended, realistic assignments that are not so far from project tasks. We use unit testing to check assignment solutions, as we would do for project contributions.
  • Grades and transcripts: We would need to organize projects and subjects carefully to make sure that we can certify a level of accomplishment in different subjects. In fact, this wouldn't need to be that different from what we do in a traditional program. As students progress, they move to positions of greater responsibility in their chosen projects and their roles demand more advanced subjects. A freshman might do basic program maintenance tasks that require her to read specifications and bug reports, read and understand varied code, and modify it to pass existing unit tests and new ones she would craft. With faculty guidance she would take on a number of different such tasks to learn about different programming concepts and paradigms. Later, she would be assigned to select and implement (or get from libraries) the best data structures for various tasks, producing also documentation that explains rigorously the complexity arguments in favor of her choices. All of her contributions in different subjects would be evaluated and packaged into subject bundles that would lead to transcript entries.
  • Do it right away: I keep bringing this up, that when I'm asked to do something new, I reply asking what you want me to stop doing. A school interested in going this way would have to allocate start-up resources to release a coherent faculty team to put a pilot program in place. Given the challenges of current academic finances, with decreasing real-dollars research funding, shrinking enrollments in areas like computer science, and downward pressure on tuition increases while expenses like health care explode, it won't be easy to convince an administration to come up with the money. But it might be possible to build something incrementally by converting more advanced applied subjects first (operating systems, databases, AI, ...) and spreading into the more basic parts of the curriculum as the demonstration succeeds and is able to attract resources from grants, for example.

No comments: