I’ve run real computational science projects for four years now in my year 11 Computer Science class. Some have been run-away successes, and some have been… well… challenging to make work. It’s been a learning experience for both me and the kids, and I’m starting to put together the key criteria that make it successful. I’m starting with Computer Science/IT projects, but there’s no reason this can’t be expanded into other curriculum areas – even Primary School.
This post is a summary of what works and what doesn’t. Over time there will be more detailed posts about the individual projects – written in my copious free time. 🙂
First, what works.
- Keep it real. The most important thing from a motivation perspective is make it a real project. Make it something that could make a difference to the world, even if only in a small way. This is by far the loudest bit of feedback I ever get – “doing something real was SO AWESOME!”. So work with someone who needs something. Simple ideas are to automate some data task that people currently do by hand – anything from school enrolment processes to membership management for local clubs. Take a tedious and repetitive task and make it easier for someone. We have done projects for scientists who know what they need but don’t have the computing skills to create it themselves, and for organisations focused on sustainability.
- Make it altruistic. Students love justice, fair play, and looking out for people or things that can’t look out for themselves. Offer them a project where they can make a difference to a charity or a local community organisation and it will boost their self-esteem immeasurably, and stoke their motivation to intense levels. Writing software, websites etc for businesses that won’t pay them generally just makes them cynical rather than motivated – and who can blame them? Get them creating websites to teach asylum seekers computer skills, or to connect volunteers with projects – or better still give them a set of skills and tell them to find an organisation that they can help with those skills, which brings me to…
- Wherever possible, let them create their own projects. By far the best work I have seen so far has been from kids who have taken the opportunities I’ve offered and run with them in their own creative directions, building their own projects out of their particular skills and ideas. This is real problem based learning – I’ve shown them a problem area or introduced them to an organisation or scientist with some data and some problems, and they have come up with new and innovative ways to help. It’s crucial to give them room to spread their wings in a way that appeals to them. Sometimes this means having to rewrite the assignment to make room for what they want to do, but it’s worth it if they are essentially meeting the criteria, because their motivation will be so much higher if they’re working on something they have designed from scratch. But not all students have the skills or the enthusiasm to do this, which means you have to…
- Make sure it’s scalable. As a general rule you need to have a few base level problems that are achievable for the lowest level of skills in your class, and your assessment criteria need to be such that kids can do well by doing a thorough and high quality job on these manageable problems. For the problem sets where you’ve got real data, this is relatively easy – they can “clean” some of the data by removing inconsistencies and flagging any issues with the data, and/or do some basic stats on the data. For my projects the assessment is around planning (problem specifications and problem decompositions), usability and robustness, documentation (both of code and for users), and usefulness. Only the best projects will achieve the top score on usefulness, but any project can achieve high scores on the rest of the criteria, if it’s well done.
- Make them submit early project specifications. This is so you can sanity check their projects, make sure they have fallback positions for any projects that are wildly ambitious (a kind of minimum criteria for success: “We really want to do THIS, but we’ll be happy with getting this far“), and be sure that they are not planning to create an artificial intelligence or solve world hunger in time for tea. It also forces them to think their projects through and make sure they know what they are doing from the start. Once they have specified it, they can decompose it into discrete tasks that can be allocated to different group members (for group projects). Even for individual projects, the decomposition is important, because it breaks a large scary project into achievable milestones.
- Allow the problem specs to change over time. Sometimes a group will start one project and then come up with a better idea. Sometimes they’ll fall short of what they wanted to achieve in unpredictable ways. It’s important not to tie their final mark to a perfect implementation of what might turn out to be an imperfect specification.
- If you can, take the students to see the context of their project. For most of my projects I have the partner organisations come in and talk to the students at the school, but for the dolphin project we were lucky enough to be able to go out on the boat and see the context we were working in as well. The interesting thing is that the boat trip happened after the subject had finished, the assignments were all submitted, and even marked, but over and over again the students tell me that it still made a difference to the overall impact of the project. So even if you can’t do it until the end, go see the context of the work if you possibly can. Meet the people involved. See the impact of the work.
Now to what doesn’t work.
- Highly technical projects without a fallback position. Projects that mean students have to wrap their heads around a complex system, such as Django, where there isn’t a fallback achievable option are really dangerous. Ditto projects that aim super high and have no intermediate achievement levels – you have success, or you have nothing. Even if you can mark what they have done fairly, students leave these projects feeling dispirited. It’s really important that they can point to something that they have achieved.
- Projects where success or failure are dependent on external factors you can’t control. You need to have access to everything needed for the project at the start. Discourage students from choosing projects reliant on data they might not be able to get, or on input from external people. Where group projects are interdependent, make sure that they have independent success criteria, so that each group or group member can be evaluated separately if one crashes and burns (this is where early project specifications and decompositions are incredibly valuable).
- Contributing to existing code bases. I’m being a touch unfair saying this never works, but it is hugely risky, and only for the highly skilled. There is a lot of terrible code out there, and making a project reliant on deciphering someone else’s code, particularly from a real project, adds a huge startup cost before they ever get to produce something themselves. Sometimes simply understanding a system is a herculean task, but it doesn’t come with a sense of achievement or measurable outcomes. So I’d strongly discourage this kind of project. I had several of these in my project set a couple of years ago, and they were really tough on the kids. They learnt a lot, but they didn’t come out with much of a tangible result, which was hard on their morale.
Overall, real projects are an incredible motivational boost. They are a little more work to setup than artificial projects with fake data, but they are also vastly richer learning opportunities. In all, I think the effort is worth it. And certainly the feedback I get from students makes it clear that they agree.