Extreme Programming In The Classroom
Extreme Programming In The ClassroomOne thing I like about ExtremeProgramming is that it captures so many of the things that I've been trying to teach my students about how to program: start small and grow slowly, refactor often, how to really use a design pattern, and so on. But, clearly, ExtremeProgramming is not the ordinary way in which students are taught to program in school.
So: Do any of you have any advice on how to introduce the principles of XP into my class room? I'm not talking about a methodology course but rather a CS 101 or CS 102 course where kids first learn how to program. How can I help students to develop good programming habits? I'll go ahead and create a page for a discussion of ExtremeProgrammingInTheClassroom, just in case you all have plenty to say!
I asked KentBeck about ExtremeProgrammingInTheClassroom at the OOPSLA ice cream social. One piece of advice he gave me was to have programming assignments involve PairProgramming and to have students record their experiences working in pairs as a part of some course deliverable. I do this in my senior-level Intelligent Systems course (a project-based course taught in a studio format), but I've never tried it with freshmen or sophomores. -- EugeneWallingford
When I teach a sophomore-junior level course on assembly language programming and C, I always have students work in pairs. This isn't exactly the same thing as PairProgramming because I haven't given them much advice on how to work together. In the future I will give them the further rule that any time they touch the computer to work on the problem, they must be working together. In fact, working on the program without their partner is equivalent to cheating! They can draw pictures on their own, read listings of the program on their own, and certainly think on their own. But when they edit the program, they must do it with their partner. I think that will be enough of a rule to force students down the PairProgramming path.
It would also be helpful to have a one-page description of a pair programming session so they can see things like "one person drives, the other one talks", and the fact that you often switch drivers.
Testing is another important thing you can teach. It is typical for the teaching assistants to have a test suite that they use for grading. Students should be required to hand in a test suite that runs, as well as tests that don't run. They will get less points taken off for a bug if they can illustrate it.
Refactoring should be taught by example. In class, you explain several ways to do something, and discuss the merits of the various ways. Give some examples when you start to do things one way, then change your mind and do them another. I think an intro course is too early to make a big deal of refactoring, but students should get the idea that programs are malleable and it is more important to make the program right for the current situation than to have it right at the start, because the definition of "right" might change.
-- RalphJohnson
In much of the "real world", the IT departments of businesses in particular, refactoring is not taken for granted. In fact, it is commonly viewed as wasteful and even dangerous. It's perfect for intro-level students to see refactoring used in a natural, casual way. Don't obscure the point of the example by making it 98% refactoring and don't get into the whys and hows. Don't make a big deal of it so that they develop the attitude that it ain't no big deal. -- KielHodges
Definitely teach CodeUnitTestFirst: I wish I'd learned about it a long time ago. Granted, my professors did stress designing the interface first, then doing the implementation - but CodeUnitTestFirst goes further, showing you how the calling code will actually look (example code vs. nice javadoc output).
In lectures, you don't need to completely flesh out the test cases, but you should at least write the method calls and assertions they'd contain (pseudo-code is fine, especially for assertions).
For practical assignments, encourage the students to CodeUnitTestFirst. Give them some good arguments for developing in small increments (e.g. you know exactly where the bug was injected, you always have a running system) and having UnitTests (e.g. you can refactor without fear, they constitute example code for using your classes).
But beyond that, encourage them to measure for themselves: give two (small) assignments of comparable complexity; make them do the first without doing unit tests first, the second with; have them measure how much time they spend on various activities (coding, finding bugs, fixing found bugs) and in total.
Personally, I find that when I CodeUnitTestFirst, I write the code in about the same amount of time, but I end up with good UnitTests, better code, and better implementations ForFree. -- GeorgePaci
Here's one idea I presented informally at TorontoXpUsersGroup. I was pitching a programming class to a local adult education centre, so the audience was students who don't know much about programming. The idea never got off the ground, and I've never tried the following method, but it's an idea anyway.
During lectures, keep some IndexCards handy. Anytime anyone has a question, before answering it, write it down on a card. Then choose one other student (at random) to see if they can help answer the question. If they do have a correct answer, or even a partially correct answer, write it down on the back of the question card. If they do not, then ask the rest of the class for contributions. If no one has an answer, or if the answer is incomplete, the lecturer answers the question and write is down on the back of the card. At the end of the day, you have some cards (hopefully; this requires participation on the part of the class).
The next day at some point, take a break to go over some of the question cards. Leaving it for the next day will give you a chance to double check your answers. Select some from the beginning of the deck. Ask the question that is written on the card to a random student. If the student answers correctly put a check mark on the card. If they offer any new good answers, add them to the answers already on the back of the card. If it is not answered satisfactorily, put a cross on it. In any case, go over the answers on the back of the card with the entire class. Put the card at the back of the deck to cycle through the deck. After a few days, you will have a bunch of question cards. Some will have been reviewed often, some not reviewed at all.
Once a card has been reviewed five to seven times (or whatever; I heard somewhere that seven is a good number of repetitions to learns something), take it out of the deck. This will keep the deck manageable while offering enough repetitions to learn from. When it comes time to write up a test, you will have a bunch of cards with questions and answers on them. Use these cards to develop the test, along with standard text-book-style questions. The best cards to put on the test would be those that were answered correctly about half the time, although some easy questions and some hard questions will help normalize the grades.
You can even let the students know how you're developing the test and offer them copies of the cards as study material.
Some advantages of a method like this:
EditText of this page
(last edited May 28, 2004)
or FindPage with title or text search