Beginning programmers seem to like monolithic code. Give them a task to program and they start right off. writing everything in one huge method. If you assign them to use a specific method for a specific task they will do that. And the rest of the code will be monolithic. It seems to be hard for them to design code with small modules though. At least it seems they have to be taught to do so. It doesn’t seem to come natural.
Or maybe it’s just the teacher my students suffer with.
In any case, at this point in the semester I am really pushing breaking things down into small pieces and creating methods to handle things. We really just learned about methods in any detail in this first semester programming course so I can understand it not coming natural. On the other hand, we just went into methods in depth and usually students want to use the new thing they have just learned. But not in this case.
This morning I read though all of their code so far. Yep, lots of monolithic code. I spend the first 20 minutes or so of class discussing the different projects they are working on and explaining how I would break up some of the work into individual methods. It seemed to register a bit. I think that some of them who are having trouble debugging their code, in part, because they are trying to code and test “everything” at once, will really benefit from today’s discussion. I hope so.
Clearly though as we are moving into more complicated projects I need to spend more time talking about design. I’m looking back though my plans from earlier in the semester to see where and how I can talk design long before this point.
The other thing I would like to do is design a big project that requires lots of methods. The idea would be to randomly assign the methods to different students and have a test bed that calls the methods. Students would not know whose methods would be tested with theirs in advance. That way there could be no collusion to bypass the strict specification of inputs and outputs.
My hope is that this would show students the value of methods in larger projects. It should also help them understand the importance of design, specifications, documentation and working as part of a team. I just have to figure out the right project.
3 comments:
Logo "flowers" came into my mind as I read through this post. As I recall, the Logo process developed from creating a base shape like a square then a rotation loop to repeat the square "method" followed by the named routines (like methods) for making a stem and leaves.
It might help to use a quick review of the Logo process before jumping in with methods in your preferred code-teaching language. The relative simplicity of Logo and its very visual nature could stimulate a good methods discussion and adoption.
This is one of the reasons I grade project in modules. They have to show me the various modules (methods in code) before I let them start coding. Trying to get kids away from the keyboard is a constant struggle. "Plan it before you type it" seems to be against their nature. What would be nice is if I could come up with a set of projects that use methods from previous projects. If they wrote the previous project in small parts they just have to reuse the parts.
In our AP classes, we've found that when we go "control structures first" the kids tend more to monolithic mains but when we go object/methods first, even though it gives us a more limited tool set in the beginning the kids are more inclined to break things up.
Post a Comment