TITLE: Learning from Projects in Industry Training AUTHOR: Eugene Wallingford DATE: August 13, 2010 8:42 PM DESC: ----- BODY: Former student and current ThoughtWorker Chris Turner sent me an article on ThoughtWorks University's new project-based training course. I mentioned Chris once before, soon after he joined ThoughtWorks. (I also mentioned his very cool research on "zoomable" user interfaces, still one of my all-time favorite undergrad projects.) Chris tool one of my early offerings of agile software development, one that tried to mix traditional in-class activities with a "studio approach" to a large team project. My most recent offering of the course turned the knobs a bit higher, with two weeks of lecture and pair learning exercises followed by two weeks of intensive project. I really like the results of the new course but wonder how I might be able to do the same kind of thing during the regular semester, when students take five courses and typically spend only three hours a week in class over fifteen weeks. The ThoughtWorks U. folks do not work under such constraints and have even more focused time available than my one-month course. They bring students in for six weeks of full-time work. Not surprisingly they came to question the effectiveness of their old approach: five weeks of lecture and learning activities followed by a one-week simulation of a project. Most of the learning, it seemed, happened in context during the week-long project. Maybe they should expand the project? But... there is so much content to teach! Eventually they asked themselves the $64,000 Question:

"What if we don't teach this at all? What's the worst that can happen?"

I love this question. When trying to balance practice in context with yet another lecture, university professors should ask this question about each element of the courses they teach. Often the answer is that students will have to learn the concept from their experience on real projects. Maybe students need more experience on real projects, not more lecture and more homework problems from the back of the textbook chapter! The folks at TWU redesigned their training program for developers to consist of two weeks of training and four weeks of project work. And they -- and their students -- seem pleased with the results.

... information in context trumped instruction out of context in a huge way. The project was an environment for students to fail in safety. Failure created the need for people to learn and a catalyst for us to coach and teach. A real project environment also allowed students to learn to learn.

This echoes my own experience and is one of the big reasons I think so much about project-based courses. Students still need to learn ideas and concepts, and some will need more direct individual assistance to pick them. The ThoughtWorks folks addressed that need upfront:

We also created several pieces of elearning to help students gain some basic skills when they needed them. Coupled with a social learning platform and a 6:1 student-coach ratio, we were looking at a program that focussed heavily on individualisation as against an experience that was one-size-fits-all-but-fits-nobody. Even with the elearning, we ensured that we were pragmatic in partnering with external content providers whose content met our quality standards.

This is a crucial step, and one that I would like to improve before I teach my agile course again. I found lots of links to on-line resources students could use to learn about agile and XP, but I need to create better materials in some areas and create materials to fill gaps in the accessible web literature. If I want to emphasize the project in my compiler course even more, I will need to create a lot of new materials. What I'd really like to do is create active e-learning resources, rather than text to read. The volume, variety, and quality of supporting materials is even more important if we want to make projects the central activity in courses for beginners. By the way, I also love the phrase "one-size-fits-all-but-fits-nobody". When faculty who teach more traditional courses in more traditional curricula hear stories such as this one from TWU, they always ask me the same question: How much does the success of such an industry training program depend on "basic knowledge" students learned in traditional courses? I wonder the same thing. Could we start CS1 or CS2 with two weeks of regular classes followed by four weeks of project? What would work and what wouldn't? Could we address the weaknesses to make the idea work? If we could, student motivation might reach a level higher than we see now. Even better, student learning might be improved as they encounter ideas as they need them to solve problems that matter. (For an opinion to the contrary, see Moti Ben-Ari's comments as reported by Mark Guzdial.) School starts in a week, so my thoughts have turned to my compiler course. This course already based on one of the classic project experiences that CS students can have. There is a tendency to think all is well with the basic structure of the course and that we should leave it alone. That's not really my style. Having taught compilers any times, I know my course's strengths and weaknesses and know that it can be improved. The extent to which I change it is always a open question. -----