Rethinking How to Teach Programming to Newcomers

http://bit.ly/1comZhZ
February 21, 2014

Every so often, I take the plunge and completely revamp the courses I teach. This year, after some nagging from students that they really wanted to learn more about mobile app development, I decided to introduce Android development to my first-year programming class.

In the first semester, our first-years learn logic, an introduction to Java, a study skills course, and my course, which is called Interactive Systems. I designed Interactive Systems to be a fun introduction to programming where the students come up with creative design ideas, attempt to implement these ideas, tie themselves in knots adjusting their plans, and generally come to grips with independent learning. Previously, the students made an interactive 3D pet in Second Life (http://bit.ly/1fCDLu3), but as much as I loved seeing their pets, I could not escape the feeling that Second Life was getting old and creaky. I wanted some other environment where the students could build something visual and immediate, something motivating, something of which they could be proud. Developing Android applications seemed to fit the bill, but only if I could find a way to pitch it at the correct level.

As in many universities, our first-years have a range of programming experience when they come to us: people who have never programmed before, Visual Basic hackers, increasingly Scratch adepts, and the inevitable few whose first words were in syntactically correct C. It can be difficult to find the correct pace. It seemed unfair to the novices to expect them to learn Android development at the same time they learned the basics of Java in my colleagues’ classes, yet I wanted them to have some early successes in programming. App Inventor (http://bit.ly/MJ0jfC) seemed like a good approach, so my co-instructor Gudmund Grov (http://bit.ly/1n2Kpu8) and I decided to adopt it. It is a Scratch-like visual programming environment that targets Android. Better still, it has a wealth of ready-developed, pedagogically sound teaching materials, such as Course in a Box (http://bit.ly/No9jb7). I like the flipped classroom model in which the students read textbook chapters, tried lab exercises, and then came to lectures to consolidate underlying concepts.

The practical examples that come in the textbook are well structured and easy to follow. The students liked them, but were not particularly challenged by them (in fact, I have seen a 10-year-old whiz through the same exercises). Sometimes the students told me they worked through the exercises mechanically, without really absorbing the material.

The real challenge came when we asked the students to come up with their own ideas for an app and implement it over the next 10 weeks. It can be difficult for students to estimate how difficult a task will be. The representation and features of the App Inventor interface make certain tasks (which would be hard for beginners in an ordinary development environment) trivial. For example, working with databases and using QR codes are both easy and quick to accomplish. Other tasks are almost impossible in App Inventor, or are tedious to achieve. It was therefore hard to guide students on how ambitious they should be in their designs.

Next year, it will be much easier to judge this, as we have examples to show them from this year’s cohort.

Two-thirds of the way through the course, we introduced more conventional Android development using Eclipse (http://bit.ly/Noa1VQ) and helped the students to map between the blocks’ representation in App Inventor and the Java code they were learning in their other courses. The more experienced programmers lapped up Eclipse, while the novices despaired.

At the end of semester, after a showcase of student-nominated contestants for best app, we were faced with 94 portfolios to mark, including learning log entries. These logs can be quite entertaining, and offered us useful insight into the students’ experiences with App Inventor.

Many of the students had become quite frustrated by bugs with the App Inventor environment; for example, “it [App Inventor] was still in the beta version and lots of bugs and errors kept occurring, which caused my app to fail or delete parts of code randomly.” Or, “App Inventor is very much a beta-stage product, missing some vital stuff, and while using it to complete my app, it corrupted a few of my screens, resulting in me having to redo work that had taken me a while to create.”

There is a new version of App Inventor that we will use next academic year, so I am hopeful these issues will be resolved.

Students who were new to programming certainly appreciated App Inventor, commenting: “As App Inventor works in modules, I found that I now understand how the programming process is structured better than I would have if we had dived straight in with Eclipse.”

“I remember at the start of the course remarking that App Inventor would be beneficial to me as a beginner programmer, as it breaks down the structure of conventional programming and would let me understand the big picture from the beginning. Now, when I am at the end of this course, I know that is exactly what it has allowed me to do.”

“I really loved making my app, from the design stage through to sorting out that last piece of code. It has been a nice learning curve and I can confidently say that I am proud of what came out of it.”

However, the more-experienced students were exasperated by it. Some of the more polite comments from this group included:

“At the beginning of this course, I was very excited to create my own app, as I loved programming at school and so could not wait to get started. In the early stages, I found App Inventor very easy to use and useful; however, as I began to create more complex apps, I found that App Inventor was very restrictive…I personally found Eclipse better to develop Android apps in, due to more flexibility and freedom with the software; even though this is challenging, the reward is much greater when completing each task.”

It is gratifying that this student was intrinsically motivated by problem- solving in a more challenging environment.

Another student reflected on the transition between environments as follows: “although Eclipse seems to be very difficult to get to grips with at first, after a little time working in App Inventor, it begins to become more of a hindrance than a helping tool, and the user begins to find the limits of the program.”

One of his classmates had an alternative view: “While I thought App Inventor was too simple, and as a result hindered the possibilities, I would now go so far as to say that the ease of use of App Inventor makes it a fantastic entry point for future programmers, whereas the Eclipse IDE has so many points that can go wrong and, as a result, derail the stability of the program.”

Would I recommend using App Inventor to teach first-year computer science students to program? The answer is a qualified “yes.” If you have a mixed-ability class, I suggest spending perhaps six weeks on it before moving the students on to a more fully featured development environment. If you are going to do this, the students will need a lot of support in managing the transition (taking their training wheels off!).

If you are teaching complete novices, non-computer science students, or younger students, or a course in which the emphasis is on the product ideas rather than implementation, App Inventor will be ideal, as it was developed with these scenarios in mind.

One last thought: in my experience, computer scientists love to complain about the technology they are required to use. It is part of a geek-macho culture to blame development tools in order to show one’s programming prowess. So do not take student griping to heart too much, as there may be no “Goldilocks Zone” for instructors where everything is “just right.”