Plans for APS

Next year I will be teaching Algorithmic Problem Solving (APS) in first semester, a subject that I have developed and worked on over a few years. At the start of this year I trialled portfolio assessment with some success in this subject, though I improved on this in semester 2 with Object Oriented Programming. So what am I going to do differently next year?

Greater focus on the portfolio assessment: The portfolio assessment was good in this subject last year, but the focus can be even better. I found that this helped the students focus on what was important in OOP, the intended learning outcomes. My plan is to provide assessed learning activities during the semester, the resulting work will then be included in the students' portfolios. 

Simpler book: The first few times I ran this subject we used the language manual that comes with the language we are using. Its very dry, and not presented in an order that is useful for learning. This year I tried providing my own details, but didn't really get that right. So next year I will be providing a new book.

The book is what I am focusing on now. This will use a syntax based approach to learning the language, along with clear descriptions and illustrations to help students understand the programming abstractions. At this stage I have the following sections for the book:

1. Programs - introduces the Program abstraction and a large number of new "programming language" terms such as identifier, keyword, procedure, procedure call, expression, literal, etc.
2. Creating Procedures - focuses on creating your own procedures. 
3. Storing and Using data - variables, and the assignment statement.
4. Passing Data Around - introduces parameters (both in, out, and in/out).
5. Calculating Values - covers functions and function calls.
6. External Libraries - introduces units, shows how to use external units, and provides an example function from the SysUtils unit.
7. User Input - Up to this stage we will have been using literal values, but now all of the framework is in place to understand user input. This includes ReadLn, as well as reading command line arguments.
8. Branching - Indicates the change from programming "infrastructure" to control flow, and algorithm design.
9. Looping - For, while, repeat, etc...
10. Data abstractions - now the focus changes to the programming abstractions for data. This will include arrays, records and pointers.
11. Creating Libraries - Lastly onto creating your own programming libraries

My idea for this is to have each section as self contained as possible. Knowledge will be built up without the need for any "magic". This is the reason for delaying user input... this requires functions and out parameters, with library use being necessary if you want to convert values from strings to integers for example.

These 11 chapters will be covered in the first five weeks of the semester. Week one will cover 1 & 2, week two will be 3 & 4, week three on 5, 6 & 7, week four on 8 & 9, and week five on 10 & 11. This leaves seven weeks of the semester to learn about how these abstractions are used to create programs. 

Along with this I am aiming to keep the explanation of each concept or part of the syntax down to a single page, where possible. This is enough room to convey the important aspects, but not too much that the end result is overwhelming. It should also help to create a useful reference, where each idea has its own page. So far I am up to chapter 5 which start at page 39, so there isn't too may pages per chapter.

Let me know what you think. I'll post up some chapters later...

2008 Retrospective

Well the semester is over, and I'm starting to reflect upon a year with many experiments. The big things for me this year has been trying to put into practice many of the things that I have been reading about in the education area. The main focus has been on helping students to develop a greater understanding of software development and programming in general.

Background & the idea:
Software development is challenging, something that is easy to forget (once you get it). We have taught this through extended practice, in many cases without addressing or even discussing the associated principles. One of my frustrations with this has been the way many people subsequently approach their programming, usually with little thought or understanding. The classic symptom here is observed when the student makes random changes in the hope of fixing a bug, rather than thinking through their program and reasoning about its structure and implementation.

Is this a symptom of a lack of experience, or a greater problem related to the students understanding of the abstractions they are working with.

I am of the opinion that it is largely the latter, and that by refocusing on principles and core concepts we can teach people to better understand what they are doing when they create their own programs.

The idea, for this year, has been to refocus my teaching around the core principles. Teaching the principles of structured programming in first semester, and object oriented principles in second semester.

The method:
My teaching method aimed to get students engaged with the material, it is what the student does that counts...

Along with this I wanted students to be able to be adventurous, without risking losing marks. It was more important to have good quality, that a fixed time line. I moved to an extreme "Theory Y" position, with the perceived benefits of greater flexibility for the students along with greater responsibility.

I also wanted to make better use of the lectures, by distributing weekly reading and creating podcasts and using the lectures to discuss issues students were having with the concepts.

The results:
Now that semester 2 is over I am reflecting on the results of this approach. For me it has been a real roller coaster of highs and lows. Some aspects have worked well, others need improvement.

There was a marked difference between the introductory and advanced programming subjects. In general this approach has worked well with the more advanced students (Enterprise .NET), but how about the introductory subjects?

Releasing control of the system was definitely a different experience, though not an overly positive one in the introductory subjects. During the semester it was obvious that many of these students had failed to take responsibility for their learning. This was seen through missed deadlines, lack of attendance, and few questions on challenging areas. Flexible due dates meant leaving work until the last minute, rather than a chance to do quality work. The marking then reflected this situation, with many of those who "relaxed" failing to submit anything as the workload exceeded their time remaining.

On the positive side, there were some truly brilliant portfolios submitted. Those students who did take responsibility for their learning were able to demonstrate far more than I could have wished for. I hope that these students appreciated the flexibility, and the chance to explore areas they were interested in. But how can I adjust the process to better suite the larger majority of students.

Another positive was the portfolio assessment. This was time consuming and while course grained it has given very "accurate" grades, with no students being awarded a grade higher than they deserved due to a poor testing or marking scheme. On the other hand there were some students who's result I believe could have been better if they applied themselves more to the task, and demonstrating their learning.

The lecture method worked Ok with the advanced students, but need some tweaking. With the introductory subjects it really failed, which was disappointing. I think the problems were many... The text books were really 500% of what was "really" needed. As a result many students didn't do the required reading and subsequently blundered along trying to learn details from "lectures" without any real depth to their understanding. The method was significantly different and I failed to engage them in the process. Not providing my own large design early was not a great idea. Some of the lab exercises were incorrectly focused. Some of the portfolio pieces I suggested were overly large and time consuming, without the intended benefits.

Some bad points:

• Not enough focus on programming (overcompensation)
  
• Only few truly engaged with the method
  
• In general students did a poor job of managing their learning
  
• Some students didn't end up understanding the portfolio idea
  

Some good points:

• Large responsibility on students to manage their own learning.
  
• Mature students are better equipped for this method
  
• Portfolios were able to capture student learning
  
• Assessment was "fair"
  
• No penalties for those who learn during the semester, and can communicate their learning by the end.
  
• English communication skills can be enhanced, and communication issues are less severe then with exams (which require time compressed communication)
  

Reflections & Plans:
In summary this year has been a huge disappointment, and I'll need to try and reinvigorate myself before next year. I think the approach can work, and if I can get it right there should be some great benefits for the students. Reading back over this has, however, provided me with some hope.

"Once more unto the breach, dear friends, once more;"

My plans are to focus on teaching the learning process... as well as teaching about programming :). The method is different and I dont think I spent enough time on what was expected, and how to take advantage of the environment. I also have some more practical ideas related to using more "traditional" practices alongside this to help ease students into the experience. I am also more experienced now on what I need them to focus on in this approach. It has been a long time since I really engaged with these principles, and I'll be better equipped next year.

So to my introductory programming students from this year... sorry...

I would love to know what you thought of this experience and any suggestions you have... what do you think could be done to better next time.

I also promise to blog more... if you are interested in my plans and progress stay in touch! I need all the help I can get :)

Portfolio Assessment

Well semester 1 has started... I can where did all that time go? This semester I am teaching HIT1301 Algorithmic Problem Solving again, and as always there are improvements to be made. This semester most of the changes revolve around the assessment, with some minor changes to the lectures and resources available.

On the assessment side of things the assessment will be much more flexible than in the past. Basically for APS there will be some core assignments and tests, each quite short but covering all the basics. Passing these means you pass the subject, in most cases you need to get them working to pass so dont think 50% = pass for these! To get anything greater than this students will need to submit a portfolio that shows their capabilities and depth of understanding of software development. This means students can choose what they want to focus on, while still ensuring they cover all bases. The focus of this assessment is on depth of understanding and quality of work, rather than quantity.

I'll keep you informed of how this goes... Let me know what you think of the idea.

In other news we are (well Clinton really) making progress with the new python port of SwinGame. This will mean that you will be able to call the SwinGame API from Python... the next step is to embed Python within SwinGame :)

How important is being open?

I've been so busy since I got back from leave that I haven't had ten minutes to put any of my thoughts down in writing. Today I've finally got some time to spare so I thought I would write a quick blog entry.

Over the last two years we have been planning, developing, and delivering the new Bachelor of Science (Professional Software Development) or PSD for short. This is a new degree program aimed at teaching students about modern software development, agile processes, etc. This semester I have been teaching the new Database Programming subject, the last of their programming subjects, and so I've been looking back to see how the program has turned out.

I think in general that the new degree has been quite a bit of an improvement over previous degrees, in that very few of the students "hate" programming. However I think we can improve further in some areas. The one the has surprised me the most is how fixed in their ways some of the students are. Anything that offers a slight challenge is a major obstacle, and the tool is always seems to be to blame. Its not that they are not capable of using the tools, its their attitude that I am finding intriguing. The old saying "A poor worker blames his tools" keeps popping into my mind... Having said all of this, there are also students who are doing well, and are handling the challenges in an admirable fashion. I just want to improve the odds...

I think its really important to be open to new ideas, and to be prepared to spend time to understand how a tool works. As software developers these students are going to be constantly faced with configuration/installation/integration types of problems. They will need to be able to work out how other software works in order to be able to work effectively with it.

Anyone have any ideas for how we can encourage these students to be more open in their thinking?

I want them to be inquisitive about technology, prepared to explore the potential of various solutions.

I think what shocked me most (and got me wanting to write this) was one conversation I overheard... it went something like this:

"My notebook is running too slow. I think I will install Linux and Beryl like X did."
"Really! You dont want to do that. He will have spent ages tweaking it... do you really want to do that... etc. etc."
"Yeah your right, installing Linux is too difficult... etc. etc."

This really isn't what you want to hear. Playing around with another OS is a really good learning experience, and a good working knowledge of Linux is a real advantage. Not installing it because you may have to learn how to configure it is a really lame excuse. My suggestion, install Linux. Play with Beryl. What have you lost if you end up going back to Windows? Setup a dual boot, then you can play with Windows and Linux. Learning should be fun.

Empty your Mind

Today one of the PSD students showed me what he had started for the game he was developing for Algorithmic Problem Solving. He had started on the game yesterday, and it already looks quite impressive. Basically this is going to be a scrolling space arcade game. So far he has the weapon firing in a number of shot combinations. The screenshot below shows the largest fire pattern.



Looks like some of the students are having fun with this assignment. The SwinGameAPI is a real hit, making this possible without having to worry about many complexities.

Keep the games coming...