4 ms·

This style of programming also goes by the name "code quilting". Part of the difficulty with moving this workflow method into the classroom is that it requires

This style of programming also goes by the name "code quilting". Part of the difficulty with moving this workflow method into the classroom is that it requires schools to redefine "cheating."

ser0 13y ago
Your comment about "cheating" is quite true. More specifically speaking, it's an issue with assessment in terms of confirming that a student has sufficiently demonstrated the skills/knowledge taught by the course. For a lot of programming courses, the idea is to teach programming skills considered to be representative of various levels of ability. This is usually assessed by presenting a specific problem that requires a particular solution (i.e. program a linked list or implement the observer model). In this way, the course is treated like a math course, which is not a realistic representation of general programming work. However, what the articles describe is something I think is attempted a fair bit by software engineering courses. The issue is though, in order to make it "fair" on students, they are generally given a problem with a couple of obvious solutions that are not too complex. Within an Australian context, there are several reasons for this: 1. We only have 12 week semesters, so a project can be approximately 10 weeks long at most. Generally students have one or two weeks to drop/enrol so projects cannot start on week 1. 2. The idea is for a course to require 10 hours of commitment by a student, with 3 to 4 hours taken up by class time. This leaves about 6 hours of individual work time, so 60 hours in total. For a real full-time programming project, 60 hours is basically 1.5 weeks. 3. Students are expected to take on 4 courses to represent a normal 40 hour week. Generally, I don't have too many friends that are expected to work on 4 projects simultaneously, it's simply not a good way to manage mentally straining activities like programming. But within a university setting, we have to deal with this reality. 4. Students are not all the same. If a project is very open ended, it's possible for students to select very simple projects for themselves and learn nothing. On the other hand, a student may attempt what appears to be a simple project, but have been tremendously challenging for them personally. I have found this disparity occur frequently with some high schools producing students that have experience with a range of programming paradigms and design concepts, while others produce students with no background at all. Those with experience in high school have quite the advantage compared to others when you are talking about the limited level of knowledge expected of undergraduate students. Another version of this can occur when students are given exemptions for prerequisite courses due to immigration or other graduation timing constraints. On the topic of international students, they can also come from very different cultural backgrounds and upbringings; for example, I have had students that had no idea what a stock market is. 5. Cheating and fairness. If multiple students take sample code from the same sources, it's much harder for an instructor to argue plagiarism. On the other hand, if we force students to ensure they use different sources, there exists a fairness issue with some sources perhaps offering a better, more complete solution that requires fewer customisations to solve the assignment problem. 6. Monitoring, mentoring, admin, etc. A project needs to be able to be broken up into 2+ assessments so that an instructor can identify struggling students. If a student is given a lot of flexibility and choose something like a component based software engineering approach, with most of the time spent on research, and basically implements the wrong solution, they may end up failing the course. Alternatively, they may leave everything to the last minute and turn in rubbish for open ended projects, which require a lot of planning and management. An instructor generally has to explain why a student has failed if the student chooses to appeal his/her grade; this is where evidence concerning poor understanding and documentation demonstrating attempts to help clarify the assessment is important. All of the above (and really there are many more subtle issues) mean that projects need to be simple, clearly outlined, and have clear expectations and deadlines. Given that, it's much easier to avoid the whole cheating and fairness problems by constructing an assignment that do not require additional resources, or to force students to create everything from some standard set of libraries/tools. I think wbillingsley's 100+ person project idea is very good, however, that requires a lot of work on the course planner's part. Within the universities that I have taught, the course planner also coordinates/admins, sets exams, and teaches the course. This leaves very little time for doing anything more than iterative changes to an existing course. It also appears to require relatively competent students, which is not always the case.

This style of programming also goes by the name "code quilting". Part of the difficulty with moving this workflow method into the classroom is that it requires schools to redefine "cheating."

ser0 13y ago

Your comment about "cheating" is quite true. More specifically speaking, it's an issue with assessment in terms of confirming that a student has sufficiently demonstrated the skills/knowledge taught by the course. For a lot of programming courses, the idea is to teach programming skills considered to be representative of various levels of ability. This is usually assessed by presenting a specific problem that requires a particular solution (i.e. program a linked list or implement the observer model). In this way, the course is treated like a math course, which is not a realistic representation of general programming work. However, what the articles describe is something I think is attempted a fair bit by software engineering courses. The issue is though, in order to make it "fair" on students, they are generally given a problem with a couple of obvious solutions that are not too complex. Within an Australian context, there are several reasons for this: 1. We only have 12 week semesters, so a project can be approximately 10 weeks long at most. Generally students have one or two weeks to drop/enrol so projects cannot start on week 1. 2. The idea is for a course to require 10 hours of commitment by a student, with 3 to 4 hours taken up by class time. This leaves about 6 hours of individual work time, so 60 hours in total. For a real full-time programming project, 60 hours is basically 1.5 weeks. 3. Students are expected to take on 4 courses to represent a normal 40 hour week. Generally, I don't have too many friends that are expected to work on 4 projects simultaneously, it's simply not a good way to manage mentally straining activities like programming. But within a university setting, we have to deal with this reality. 4. Students are not all the same. If a project is very open ended, it's possible for students to select very simple projects for themselves and learn nothing. On the other hand, a student may attempt what appears to be a simple project, but have been tremendously challenging for them personally. I have found this disparity occur frequently with some high schools producing students that have experience with a range of programming paradigms and design concepts, while others produce students with no background at all. Those with experience in high school have quite the advantage compared to others when you are talking about the limited level of knowledge expected of undergraduate students. Another version of this can occur when students are given exemptions for prerequisite courses due to immigration or other graduation timing constraints. On the topic of international students, they can also come from very different cultural backgrounds and upbringings; for example, I have had students that had no idea what a stock market is. 5. Cheating and fairness. If multiple students take sample code from the same sources, it's much harder for an instructor to argue plagiarism. On the other hand, if we force students to ensure they use different sources, there exists a fairness issue with some sources perhaps offering a better, more complete solution that requires fewer customisations to solve the assignment problem. 6. Monitoring, mentoring, admin, etc. A project needs to be able to be broken up into 2+ assessments so that an instructor can identify struggling students. If a student is given a lot of flexibility and choose something like a component based software engineering approach, with most of the time spent on research, and basically implements the wrong solution, they may end up failing the course. Alternatively, they may leave everything to the last minute and turn in rubbish for open ended projects, which require a lot of planning and management. An instructor generally has to explain why a student has failed if the student chooses to appeal his/her grade; this is where evidence concerning poor understanding and documentation demonstrating attempts to help clarify the assessment is important. All of the above (and really there are many more subtle issues) mean that projects need to be simple, clearly outlined, and have clear expectations and deadlines. Given that, it's much easier to avoid the whole cheating and fairness problems by constructing an assignment that do not require additional resources, or to force students to create everything from some standard set of libraries/tools. I think wbillingsley's 100+ person project idea is very good, however, that requires a lot of work on the course planner's part. Within the universities that I have taught, the course planner also coordinates/admins, sets exams, and teaches the course. This leaves very little time for doing anything more than iterative changes to an existing course. It also appears to require relatively competent students, which is not always the case.