Pretty sneaky, Sis

I've always lamented the fact that we don't have the time or structure to really teach our kids to program.

In their early classes, they learn syntax, algorithms, and  some ways of storing data and while they  will probably work on some larger projects as they study CS, kids seem to be mostly left on their own in terms of how to take a project from problem or idea to completion.

This frequently leads to poorly designed projects that are harder for the kids to write, debug, and modify. They end up with huge functions/methods no overall plan or design and everything's pretty much a mess

To try to address this, and having finished  most of the A.P. curriculum and not wanting to diverge from the other teachers, I figured we'd develop a class project before I gave the class time for their final projects.

I'm not a huge game person, but since they decompose well, we decided on writing connect 4 - a game that can be described as tic-tac-toe but with four in a row, on a larger board, and WITH GRAVITY!!!!!!

Actually, the choice of project didn't matter that much so long as it was the right size -- this was more about how we develop a program than about the actual program itself.

I started by giving my classes about ten or so minutes to talk among themselves to design the program -- no guidance was given. About seven minutes in, I asked them to reflect on whatever they were discussing - if they were discussing a data structure, why? If class design, why? What was so important about whatever they were discussing that made it their first order of business.

After a while, we started to share thoughts as a group. Most suggestions revolved around details -- how to you check for a winner, how do you make a move. This made sense - we've spent much of the term dealing with writing code fragments to do things and not too much time thinking about overall design.

This lead to a healthy discussion of looking at things from the top down as well as bottom up.

By the end of the class, we had identified the key classes we'd need (Board, Player, UI, Game Driver) and had some idea as to how they would relate to each other. By the next morning, we added a data structure for the board.

Over the next few days we filled in the missing pieces. We moved up and down levels of abstraction being careful to discuss why we designed things the way we did and adapting pieces as needed.

By the end of the project we were able to accomplish the following:

• Students saw how to have classes refer to each other - that is, the Player class had an instance variable to hold the board, while the Game class had instances for Players as well as the Board). 
• We were able to use different user interfaces for the program -- starting with simple console input and then moving to a GUI -- all we had to do was extend the UI class.
• Likewise, implementing a computer player (albeit a rather limited one) was trivial.
• I also tried to show frequent testing and the idea of developing one concept at a time.
• We discussed the idea that while design is important, there's a point where you can over design. Be aware of the scope of a project, what can generalize, and what shouldn't.
• With a good design, it was also trivialize to change things like game rules, how to move, board size. etc.

Based on preliminary feedback, I think the students have a much better ideas as to how to break down, design, and build up a project from design to implementation.

If any one's interested, the code is available here.

We'll see if it helps with the final projects, but I'm optimistic.  Spending time highlighting the design and development process while building a project can only help.

Anyone else have interesting mid-size projects they do with their classes?