This week's book giveaway is in the OCMJEA forum.
We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line!
See this thread for details.
The moose likes Teachers' Lounge and the fly likes What do think about labs? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Books » Teachers' Lounge
Bookmark "What do think about labs?" Watch "What do think about labs?" New topic
Author

What do think about labs?

Kathy Sierra
Cowgirl and Author
Ranch Hand

Joined: Oct 10, 2002
Posts: 1572
Howdy -- we had a big controversy at Sun over what the labs should be like for the in-class hands-on exercises for Java.
The arguments were like this:
* Labs should be very real world; students should be doing things almost exactly as they would in the real world. That may include having the student do only small pieces of some larger project.
* Labs should be greatly simplified versions of something that *might* scale to the real world, and you can show them how it might scale, but the actual in-class lab is something they can complete themselves.
* Labs do not have to be real world, as long as you can show that the thing they're practicing -- the objective of the lab exercise -- is something that *does* map to the real world (which you can demonstrate with examples).
* Labs do not have to be completed.
* Students can be given the solutions in advance.
* Students should NOT be given the solutions in advance, but must try to figure it out on their own.
* Students should NOT be given the solutions in advance, but can be given hint sheets, with progressively graduated hints
* All students should be doing the exact same thing.
* Different students can work on different labs, you can give them an option
* Labs should be scalable, so that everyone must complete a baseline level, but more advanced students can go on to implement some more advanced (but optional) functionality, or at least they can be given a list of suggestions on things they might want to do (while they're waiting for the rest of the class to finish.)
* Labs should be done in pairs.
* Labs should be done alone.
These are just *some* of the issues!
I won't tell you which of the above bullet points are mine (although you might be able to guess). But I'd love to hear other thoughts on your own experience and view of hands-on lab exercises. Note: I'm talking just about hands-on programming labs, not other kinds of exercises.
cheers,
Kathy
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
I find that when labs are done in pairs that one student tends to do all the work and the other learns nothing.
I find that it is much easier to discuss a lab with the entire class if the entire class is working on the same lab. Otherwise I end up spending too much time with one group.
I agree that labs do not have to be completed. I give sufficient time to do it and let students that didn't finish take it home with them.
I don't give the solution in advance but I do answer questions and give hints for those who need them.
Labs should be scalable, so that everyone must complete a baseline level, but more advanced students can go on to implement some more advanced (but optional) functionality, or at least they can be given a list of suggestions on things they might want to do (while they're waiting for the rest of the class to finish.)
I agree with this.
Labs should be geared toward the lesson. Often trying to make things "real world" brings in too many complexities that distract from the purpose of the lab.


Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Johannes de Jong
tumbleweed
Bartender

Joined: Jan 27, 2001
Posts: 5089
Labs should be very real world; students should be doing things almost exactly as they would in the real world. That may include having the student do only small pieces of some larger project.
I think this is the most important one for me. I really think that there shoud be one universal project that should be defined and that all IT related training should use it as its base. Even books should use this.
I personally think that in courses too much time is wasted in describing the project.
Butt hen what do I kow.
Kenneth A. Kousen
gunslinger & author
Ranch Hand

Joined: Sep 18, 2002
Posts: 89
    
    5
This is a great topic (thanks Kathy!). I've struggled with the same issues, and don't have answers I'm all that happy with, but here's at least a contribution.
Students always say they want a single application that grows from lab to lab, but then two things happen. First, the application gets very complicated, and the students get tired of it. Second, and probably related, the application winds up getting contorted to add in all the different capabilities your discussing, rather than having them emerge naturally in their own context.
An example of this is in the _Applied Java Patterns_ book by Stelting and Maasen. They apply almost every pattern to a single application, which is supposed to be a PIM Manager for a handheld device. (It's not J2ME; it's just an example app.)
The PIM grows from an address book and scheduler to eventually providing cost estimates of major projects with tasks and deliverables. That always feels wildly unlikely to me, plus it makes the code very complicated. When I'm talking to students, they start rolling their eyes about yet another complicated function applied to this PIM system.
When I make materials, I tend to make multiple lab assignments, some of which build up and some of which do not. That way the instructor can decide which assignments to do at the time. If the students have lost the forest for the trees, they can do the individual, self-contained labs. If they need to see a growing app, they can do that instead. I don't expect anybody to do them all, though I give solution packages for all of them.
I'm not big on giving them pre-built sections and telling them to fill in the blanks. That's so much like a solved problem that the students tend to rush to fill in what's missing without thinking about what they're doing.
I like the idea of giving short descriptions of what to do that still allow for some creativity, and then giving them one possible solution, which I go over in class. Actually, I give them all the solutions in subpackages of the main structure, but when we go over the labs, I tend to write out a slightly different solution as we go. I'm a very fast typist, though, so I can usually get away with that. I think many of the less experienced students need to be able to refer to the solutions during the labs, too.
I also like the idea of paired programming. I like extreme programming anyway, plus my experience is that the student who isn't actually coding is actually learning a lot by not becoming bogged down in syntax.
What I do in academic classes is give the students a set of interfaces to implement, for which I already have JUnit test cases. When they upload their submissions, I just change the package under test and execute the test cases, and know immediately where the problems are.


Kenneth A. Kousen, Ph.D. (assorted certs), President, Kousen IT, Inc.
Author of Making Java Groovy - http://www.kousenit.com
Pauline McNamara
Sheriff

Joined: Jan 19, 2001
Posts: 4012
    
    6
Note: I'm talking just about hands-on programming labs, not other kinds of exercises.
What? No aerobics?

"other kinds of exercises" - you mean like how to use a program as opposed to how to write code?
[ August 20, 2003: Message edited by: Pauline McNamara ]
Pauline McNamara
Sheriff

Joined: Jan 19, 2001
Posts: 4012
    
    6
These ones I generally agree with:

* Labs should be greatly simplified versions of something that *might* scale to the real world, and you can show them how it might scale, but the actual in-class lab is something they can complete themselves.
* Labs do not have to be real world, as long as you can show that the thing they're practicing -- the objective of the lab exercise -- is something that *does* map to the real world (which you can demonstrate with examples).

These 2 make sense to me. The classroom *isn't* real life, but connections can be made.

* Students should NOT be given the solutions in advance, but can be given hint sheets, with progressively graduated hints

I like the idea of progressive hints, from a learner's standpoint too.


* Different students can work on different labs, you can give them an option
* Labs should be scalable, so that everyone must complete a baseline level, but more advanced students can go on to implement some more advanced (but optional) functionality, or at least they can be given a list of suggestions on things they might want to do (while they're waiting for the rest of the class to finish.)

Flexibility, nicer for everyone.

* Labs should be done in pairs.
* Labs should be done alone.

Encourage pairs, but give them a choice, I think. *Most* will do that. I wouldn't let a timid beginner get stranded alone nor get paired up with a know-it-all bulldozer. You can't force social skills that they might not have. :roll: Kenneth's point about the one not typing being able to keep track of a bigger picture makes sense - might even be good to have pairs switch roles now and again.
[ August 20, 2003: Message edited by: Pauline McNamara ]
Kathy Sierra
Cowgirl and Author
Ranch Hand

Joined: Oct 10, 2002
Posts: 1572
Originally posted by Pauline McNamara:
Note: I'm talking just about hands-on programming labs, not other kinds of exercises.
What? No aerobics?

OK, you have no idea how funny that IS to me... in my former life, that *was* my profession (if you can call it that). So when I first started teaching programming classes, I would frequently threaten the students with push-ups or other physical exercises. And every once in a while, I almost *forgot* that I couldn't just start ordering them around. I will say one thing, though, I like to make my "live" students move around the room on a regular basis, or at the very least -- stand up and stretch fairly often. And I make them do it, as a group. The first few times they look at me very strangely when I say, "OK, everyone stand up now." They stand and wait... then I say, "OK, you can sit now." And that's it, no explanation. But even that simple act helps re-energize them.
Non-related note -- I just read something that said putting water to drink INSIDE the classroom improved students overall scores, significantly. In other words, having a pitcher of water and glasses, or bottles of water, or at least a water fountain of some sort, made a fairly big difference over classrooms that didn't have this -- EVEN when the no-water students still were allowed to *bring* water in.
They did say that it helped even more if the teacher frequently reminded students to drink.
More and more and more I keep reading that dehydration is the most likely cause of reduced cognitive function in a classroom or study session...
Oh, but for the other types of exercises I was talking about, we call them just "Pencil and Paper" or "Non-lab labs". This includes everything from quizzes, game-show style games, walk-throughs and simulations, group discussions, group presentations (where, say, two students go to the whiteboard and try to demonstrate something)... basically *anything* that isn't a formal hands-on lab. We try to do as many of those as possible. For example, in the EJB course we would have a handout that showed the whole complex lifecycle, with arrows coming in and out of the different pieces, and then we would have the students number each of the arrows for the order in which they occurred, and then one pair of students would volunteer to go to the whiteboard (where we drew the same picture) and number them, telling the story about WHY they numbered it like that, as they go. Then the other students had to decide whether their story was a good one... things like that.
Another is to have different people play the *role* of the various pieces of an EJB transaction -- one person is the container, one person the EJBObject, one person the bean, one person the database, then we'd give them scenarios like, "The transaction coordinator is using two-phase commit -- you are all players in the transaction, but bean #2 cannot commit... act out the whole process start to finish.
Bert and I also have students get up regularly and stand in a big circle, then we throw something (bean bag, foam ball, etc.) to someone in the circle and ask a question (these are always simple review questions). They can choose to answer it, or throw it to someone else to answer, then it keeps going. We do reviews this way, especially after breaks, or when they're looking sluggish and tired...
cheers,
Kathy
Johannes de Jong
tumbleweed
Bartender

Joined: Jan 27, 2001
Posts: 5089
Hmm your classes sure sound like great fun Kathy
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
It might be just me and one of my many "ranting points", but one thing which upsets me about lots of the "lab exercises" I have studied and taught is that they seem set up to reward overcomplexity and bloat rather than simplicity and effectiveness. I would add a vote for exercises with simple, testable goals rather than "your solution should include the following ...".
Maybe you all take this for granted, but it's extrememly uncommon where I work.


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Originally posted by Kathy Sierra:
Howdy -- we had a big controversy at Sun over what the labs should be like for the in-class hands-on exercises for Java.

Um, this looks like an interesting topic, but I have no idea how to pick a side. What was the purpose of having the labs?
Labs's are great for some things, bad for others. Until we know the goals of this particular program, it's argue to argue whether or not a lab can achieve those goals.
--Mark
Kathy Sierra
Cowgirl and Author
Ranch Hand

Joined: Oct 10, 2002
Posts: 1572
Originally posted by Mark Herschberg:

Um, this looks like an interesting topic, but I have no idea how to pick a side. What was the purpose of having the labs?
Labs's are great for some things, bad for others. Until we know the goals of this particular program, it's argue to argue whether or not a lab can achieve those goals.

Well, that's actually part of the question we should be discussing, I think.
What the heck ARE hands-on labs supposed to accomplish? I'm not sure that among the folks I worked with, we ever fully agreed on that, for Java anyway. I taught other classes where the lab goal was simply practice and skill building, but that's certainly not always true for Java.
OK, so for the very beginner classes, there *is* a certain amount of just time-on-task writing - compiling - running so that they're not struggling with the tools/environment. But after that... what IS the goal?
Often, when I had to teach from existing courseware (especially when I had absolutely no hand in the course content), I really didn't KNOW. Some of the labs appeared more like *typing* exercises.
Others appeared like they were difficult just for the sake of being 'challenging' rather than being difficult to reflect the actual difficulty of the THING they're supposed to be working on.
Some seemed to be more about having them work out some complicated algorithm, when the logic behind that algorithm was NOT the thing they were supposed to be "learning". (Like, an EJB lab where they're supposed to learn how the three pieces fit together -- the home, component, and bean -- but they're so bogged down in the requirements of the business logic for one method, that they're frustrated and struggling with THE WRONG THING. That one drives me crazy.
But mostly, they seemed to be put in because, "We have to have a hands-on lab at the end of each module." Whether it made sense or not. Whether some *other* form of exercises would have been better at that point...
So it's not as clear-cut with a Java developer course as it might be for other courses.
What are the criteria we could use to determine what the goal *should* be, so that we can determine if the lab in fact supports that goal?
For example, here are a couple questions we might look at (assume that we're past the initial edit-compile-run tools/environment practice stage)
1) Is practice a good thing in and of itself -- just for the sake of practice? Should this be done on 'paid' time, in the classroom, or are we wasting their time?
2) Under what circumstances should labs possibly lead them into new territory -- having to *apply* what they've learned to a completely novel situation, or perhaps extrapolate things...
hmmmm....
Kathy
Kathy Sierra
Cowgirl and Author
Ranch Hand

Joined: Oct 10, 2002
Posts: 1572
Originally posted by Johannes de Jong:
I think this is the most important one for me. I really think that there shoud be [b]one universal project that should be defined and that all IT related training should use it as its base. Even books should use this.
I personally think that in courses too much time is wasted in describing the project.

I wanted to come back to this one. Perhaps my biggest complaint at Sun Ed was the issue that there was too much cognitive overhead just in *understanding* the project or else in just figuring out *what* they were supposed to be doing.
Assuming that the *actual* task was not that difficult to understand, the not-knowing-what-they're-supposed-to-be-doing problem seems much more a product of poorly-written instructions, and the teacher not bothering to make up for that with better introduction of the assignment.
But the big problem for me, Johannes, as it is with you -- is when the project and/or domain is just too damn complex. There are only so many brain cycles to go around for any particular 'learning experience', so I'd much rather seem them spent on whatever the goal really is (assuming we've figured that out )
On the other hand, I have not figured out how to make The Universal Project stay fresh and interesting. Johannes, I suggest we start this as a separate topic and you bring people up to speed a little on the idea. I know *I* am interested in talking more about that. We're doing with the EJB book, more or less. But it's a lot easier with such a focused API... anyway, I have a lot of questions swirling around about that, so if you bring it up in a topic, I'll be there
cheers,
Kathy
Kenneth A. Kousen
gunslinger & author
Ranch Hand

Joined: Sep 18, 2002
Posts: 89
    
    5
The meta question appears to be, "what's the purpose of labs anyway?"
1. I believe it's supposed to be the "I do and I understand" part of the old cliche about learning.
2. In my experience, even in my Intro Java courses students are still coming from a programming background, and coders always want to code. The lessons don't sink in until they've actually written some code, seen in compile, and run it.
That said, I've run into courseware where the "exercises" all boiled down to typing (the IBM stuff I've seen is notorious, but I've heard MS is the same way). That's easy for the instructor, because the length of the labs are somewhat predictable, but I often wonder if it helps the students much at all.
The labs I like are ones that give rough descriptions of the required functionality, and lets the students write the answers themselves. That means the lab itself can't be too complicated, of course, but a couple of sentences description is often sufficient.
In an Advanced Java course teaching about threads, for example, a lab consisted of "Write a class that extends Thread and reads a file. Give the class a constructor that takes an integer to act as the object's ID. Instantiate three instances of your class with three different ID's, have them each read the file five lines at a time, and output those lines along with the object's ID. Have the output alternate by calling Thread.yield()."
(This is paraphrasing a lab from ITCourseware.)
I think that's reasonably straightforward, but still allows for a bit of creativity.
3. In an Intro Java course, the most important thing (IMHO) for labs to accomplish is to get the students to think like OO programmers. The syntax should be simple, therefore, in favor of interesting demonstrations of classes, objects, inheritance, composition, poly-wanna-morphism, etc.
4. I'm still toying with the idea of incorporating JUnit into many of my labs, the way I do in my academic courses. By that, I mean that I'd give the students an interface to implement or an abstract class to extend, where I already have JUnit test cases worked out. Then, when the students finish writing the labs, they can run the tests and see how successful they were. Then we can go over them and talk about programming style, but at least that keeps the focus on successfully implementing the required tasks.
5. If you're going to have a larger project that grows from lab to lab, the students have to have all the intermediate stage solutions. That way if somebody misses a lab, or if they're just stuck on one part, or they decide they don't feel like doing a particular part, they can just copy the solution and use that to start the next lab. I put all the intermediate solutions in sub-packages, and Eclipse (for one) will allow me to just copy the files from one package to another and automatically fix all the package statements.
Again a long winded answer. Sigh. Sorry about that.
Ken
Johannes de Jong
tumbleweed
Bartender

Joined: Jan 27, 2001
Posts: 5089
Kathy said : so if you bring it up in a topic, I'll be there
I'll bring up the topic sometime in the weekend.
Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
* Labs should be very real world; students should be doing things almost exactly as they would in the real world. That may include having the student do only small pieces of some larger project.

Labs should mimmick real projects in procedure, never scope.
If students get to do a small part each of a larger system, the teacher should make sure that each part has similar content and complexity (else some students might not learn everything the lab has to teach).
* Labs should be greatly simplified versions of something that *might* scale to the real world, and you can show them how it might scale, but the actual in-class lab is something they can complete themselves.
* Labs do not have to be real world, as long as you can show that the thing they're practicing -- the objective of the lab exercise -- is something that *does* map to the real world (which you can demonstrate with examples).

If the purpose of the lab is to teach realworld techniques, make it a realworld project including realworld requirements.
If it's to teach programming concepts and principles, many things like robustness can be played down and deferred to a later course.
* Labs do not have to be completed.

Why not? If the student doesn't complete the lab (s)he's failed in something. At the very least (s)he will not be satisfied (or should not be).
One of the things students should learn is the pressure of deadlines, and having penalties for non-completion without good reason (illness etc. are good excuses) does that.
* Students can be given the solutions in advance.
* Students should NOT be given the solutions in advance, but must try to figure it out on their own.
* Students should NOT be given the solutions in advance, but can be given hint sheets, with progressively graduated hints

No full solution in advance, but one can be handed out afterwards so students can compare it with what they came up with themselves.
Hintsheets are a good idea, but having a teacher (or when I went to university it was usually a fellow student helping out for compensation) sitting with them to guide them through rough waters can be extremely educational.
* All students should be doing the exact same thing.
* Different students can work on different labs, you can give them an option

I've seen both, and both can work well.
As an alternative have a series of labs over a semester which students rotate through.
This might not work as well with computer labs as copying the results of others who've done it earlier is far easier than with the results of physics experiments thus making cheating more attractive.
* Labs should be scalable, so that everyone must complete a baseline level, but more advanced students can go on to implement some more advanced (but optional) functionality, or at least they can be given a list of suggestions on things they might want to do (while they're waiting for the rest of the class to finish.)

Excellent idea. Set a minimum requirement that everyone should be able to finish in the time set, plus a few optional extras that can be completed for bonus points.
* Labs should be done in pairs.
* Labs should be done alone.

In the real world they'll usually work in groups. Making them do it in the lab better prepares them for that!
Teamwork can be taught, and this is an excellent way.
Also, by teaming weaker students with stronger ones the weaker ones might learn a thing or two.
Whether you provide permanent teamings (which we did when I was in university) or make them flexible with teams being decided for each lab separate could well depend on the personalities involved.
We worked in teams of 2 though for some larger labs several teams would actively work together forming project teams of 4 to 8 people (thus developing not only teamworking skills but also management skills).


42
 
 
subject: What do think about labs?