Posts tagged ‘curriculum’

The Story of MACOS: How getting curriculum development wrong cost the nation, and how we should do it better

Man: A Course of Study (MACOS) is one of the most ambitious US curriculum efforts I’ve ever heard about. The goal was to teach anthropology to 10 year olds. The effort was led by world-renowned educational psychologist Jerome Bruner, and included many developers, anthropologists, and educational psychologists (including Howard Gardner). It won awards from the American Education Research Association and from other education professional organization for its innovation and connection to research. At its height, MACOS was in thousands of schools, including whole school districts.

Today, MACOS isn’t taught anywhere. Funding for MACOS was debated in Congress in 1975, and the controversy led eventually to the de-funding of science education nationally.

Peter Dow’s 1991 book Schoolhouse Politics: Lessons from the Sputnik Era is a terrific book which should be required reading for everyone involved in computing education in K-12. Dow was the project manager for MACOS, and he’s candid in describing what they got wrong. It’s worthwhile understanding what happened so that we might avoid it in computing education. I just finished reading it, and here are some of the parts that I found particularly insightful.

First, Dow doesn’t dismiss the critics of MACOS. Rather, he recognizes that the tension is between learning objectives. What do we want for our children? What kind of society do we want to build?

I quickly learned that decisions about educational reform are driven far more by political considerations, such as the prevailing public mood, than they are by a systematic effort to improve instruction. Just as Soviet science supremacy had spawned a decade of curriculum reform led by some of our most creative research scientists during the late 1950s and 1960s, so now a new wave of political conservatism and religious fundamentalism in the early 1970s began to call into question the intrusion of university academics into the schools…Exposure to this debate caused me to recast the account to give more attention to educational politics. No discussion of school reform, it seems, can be separated from our vision of the society that the schools serve.

MACOS was based in the best of educational psychology at the time. Students engaged in inquiry with first-hand accounts, e.g., videos of Eskimos. The big mistake the developers made was they gave almost no thought to how it was going to get disseminated. Dow points out that MACOS was academic researchers intruding into K-12, without really understanding K-12. They didn’t plan for teacher professional development, and worse, didn’t build any mechanism for teachers to tell them how the materials should be changed to work in real classrooms. They were openly dismissive of the publishers who might get the materials into the world.

On teachers: There was ambivalence about teachers at ESI. On the one hand the Social Studies Program viewed its work as a panacea for teachers, a liberation from the drudgery of textbook materials and didactic lessons. On the other, professional educators were seen as dull-witted people who conversed in an incomprehensible “middle language” and were responsible for the uninspired state of American education.

On publishers: These two experienced and widely respected publishing executives listened politely while Bruner described our lofty education aspirations with characteristic eloquence, but the discussion soon turned to practical matters such as the procedures of state adoption committees, “tumbling test” requirements, per-pupil expenditures, readability formulas, and other restrictions that govern the basal textbook market. Spaulding and Kaplan tried valiantly to instruct us about the realities of the educational publishing world, but we dismissed their remarks as the musings of men who had been corrupted by commercialism. Did they not understand that our mission was to change education, not submit to the strictures that had made much of instruction so meaningless? Could not men so powerful in the publishing world commit some of their resources to support curriculum innovation? Had they no appreciation of the intellectual poverty of most social studies classrooms? I remember leaving that room depressed by the monumental conservatism of our visitors and more determined than ever to prove that there were ways to reach the schools with good materials. Our arrogance and naivete were not so easily cured.

By 1971, Dow realizes that the controversies around MACOS could easily have been avoided. They had made choices in their materials that highlighted the challenges of Eskimo life graphically, but the gory details weren’t really necessary to the learning objectives. They simply hadn’t thought enough about their users, which included the teachers, administrators, parents, and state education departments.

My favorite scene in the book is with Margaret Mead who tries to help Dow defend MACOS in Congress, but she’s frustrated by their arrogance and naivete.

Mead’s exasperation grew. “What do you tell the children that for?…I have been teaching anthropology for forty years,” she remarked, “and I have never had a controversy like this over what I have written.”

But Mead’s anger quickly returned. “No, no, you can’t tell the senators that! Don’t preach to them! You and I may believe that sort of thing, but that’s not what you say to these men. The trouble with you Cambridge intellectuals is that you have no political sense!”

Dow describes over two chapters the controversies around MACOS and the aftermath impacts on science education funding at NSF. But he also points out the problems with MACOS as a curriculum. Some of these are likely problems we’re facing in CS for All efforts.

For example, he talks about why MACOS was removed from Oregon schools, using the work of Lynda Falkenstein. (Read the below with an awareness of the Google-Gallup and EdWeek polls showing that administrators and principals are not supportive of CS in schools.)

She concluded that innovations that lacked the commitment of administrators able to provide long-term support and continuing teacher training beyond the initial implementation phase were bound to faster regardless of their quality. Even more than controversy, she found, the greatest barrier to successful innovation was the lack of continuity of support from the internal structure of the school system itself.

I highly recommend Schoolhouse Politics. It has me thinking about what it really takes to get any education reform to work and to scale. The book is light on evaluation evidence that MACOS worked. For example, I’m concerned that MACOS was so demanding that it may have been too much for underprepared students or teachers. I am totally convinced that it was innovative and brilliant. One of the best curriculum design efforts I’ve ever read about, in terms of building on theory and innovative design. I am also totally convinced that it wasn’t ready to scale — and the cost of that mistake was enormous. We need to avoid making those mistakes again.

June 18, 2018 at 7:00 am 6 comments

A Generator for Parsons problems on LaTeX exams and quizzes

I just finished teaching my Introduction to Media Computation a few weeks ago to over 200 students. After Barb finished her dissertation on Parsons problems this semester, I decided that I should include Parsons problems on my last quiz, on the final exam study guide, and on the final exam. Parsons problems are a great fit for this assessment task. We know that Parsons problems are a more sensitive measure of learning than code writing problems, they’re just as effective as code writing or code fixing problems for learning (so good for a study guide), and they take less time than code writing or fixing.

Barb’s work used an interactive tool for providing adaptive Parsons problems. I needed to use paper for the quiz and final exam. There have been several Parsons problems paper-based implementation, and Barb guided me in developing mine.

But I realized that there’s a challenge to doing a bunch of Parsons problems like this. Scrambling code is pretty easy, but what happens when you find that you got something wrong? The quiz, study guide, and final exam were all going to iterate several times as we developed them and tested them with the teaching assistants. How do I make sure that I always kept aligned the scrambled code and the right answer?

I decided to build a gadget in LiveCode to do it.

I paste the correctly ordered code into the field on the left. When I press “Scramble,” a random ordering of the code appears (in a Verbatim LaTeX environment) along with the right answers, to be used in the LaTeX exam class. If you want to list a number of points to be associated with each correct line, you can put a number into the field above the solution field. If empty, no points will be explicitly allocated in the exam document.

I’d then paste both of those fields into my LaTeX source document. (I usually also pasted in the original source code in the correct order, so that I could fix the code and re-run the scramble when I inevitably found that I did something wrong.)

The wording of the problem was significant. Barb coached me on the best practice. You allow students to write just the line number, but encourage them to write the whole line because the latter is going to be less cognitive load for them.

Unscramble the code below that halves the frequency of the input sound.

Put the code in the right order on the lines below. You may write the line numbers of the scrambled code in the right order, or you can write the lines themselves (or both). (If you include both, we will grade the code itself if there’s a mismatch.)

The problem as the student sees it looks like this:

The exam class can also automatically generate a version of the exam with answers for used in grading. I didn’t solve any of the really hard problems in my script, like how do I deal with lines that could be put in any order. When I found that problem, I just edited the answer fields to list the acceptable options.

I am making the LiveCode source available here:

LiveCode generates executables very easily. I have generated Windows, MacOS, and Linux executables and put them in a (20 Mb, all three versions) zip here:

I used this generator probably 10-20 times in the last few weeks of the semester. I have been reflecting on this experience as an example of end-user programming. I’ll talk about that in the next blog post.

June 8, 2018 at 2:00 am 2 comments

Teach two languages if you have to: Balancing ease of learning and learning objectives

My most recent CACM Blog post addresses a common question in computer science education: Should we teach two programming languages in a course to encourage abstraction, or just one? Does it hurt students to teach two? Does it help them to learn a second language earlier? My answer (in really short form) is “Just teach one, because it takes longer to learn one than you expect. If you teach two or more, students are going to struggle to develop deep understanding.”

But if your learning objective is for students to learn two (or more languages), teach two or more languages. You’re going to have to pay the piper sometime. Delaying is better, because it’s easier and more effective to transfer deep knowledge than to try to transfer surface-level representations.

The issue is like the question of recursion-first or iterative-control-structures-first. (See this earlier blog post.) If your students don’t have to learn iterative control structures, then teach recursion-only. Recursion is easier and more flexible. But if you have to teach both, teach iteration first. Yes, iteration is hard, and learning iteration-first makes recursion harder to learn later, but if you have to do it, iteration-first is the better order.

There’s a lot we know about making computing easier to learn. But sometimes, we just can’t use it, because there are external forces that require certain learning objectives.

I correct, continue, and explore tangents on this blog post here:

June 4, 2018 at 7:00 am 9 comments

Stanford is NOT switching from Java to JavaScript: I was mistaken

Last April, I wrote a blog post saying that Stanford was abandoning Java for JavaScript in their intro course (see post here).  The post was initiated by an article in the Stanford Daily. The post caused quite an uproar, way more than I expected. More than one Stanford faculty member reached out to me about it.  In particular, Marty Stepp told me that I was definitely wrong, that Stanford would mostly be teaching Java in a year. I promised that if I was wrong a year later, I would write another post correcting my first post.

It’s been a year, and I was wrong. Stanford is NOT abandoning Java for JavaScript.

I’m glad I was wrong, but it has nothing to do with Java or JavaScript.

I heard about the possible switch to JavaScript several months before from a Stanford faculty member.  When I saw the Stanford Daily article, I thought it was okay to talk about it. Marty told me at the time that I was wrong, and that the article was ill informed.  Still another Stanford faculty member wrote me about the tensions over this issue.

A lesson I learned from Mike Lach and others involved in the NGSS roll out is that all curricular decisions are political decisions.  A framework might be based on scientific expertise, but what is actually taught is about choice and vision — different opinions of how we interpret where we are now and what we want in the future.  If you haven’t heard about the politics of curricular choices before, I highly recommend Schoolhouse Politics.

I am not at Stanford, so I don’t know how curricular decisions have been made and were made here. I based my post on talking with some Stanford faculty and reading the Stanford Daily article.  I predicted that the forces pushing for JavaScript would end up changing the curriculum. They didn’t (or haven’t so far).  The Stanford lecturers are excellent, and they are the ones actually teaching those classes. I’m glad that they get to continue teaching the classes the way that they think is most valuable.

Below is what Marty wrote me about the courses at Stanford, and a link to the Stanford course offerings, showing that Stanford is still primarily a Java house:

This calendar year our CS1 Java course is still quite clearly the dominant course. Nick Parlante is also teaching two smaller experimental offerings of a Python class in our winter and spring quarters. There may be another experimental JavaScript and/or Python course on the books for fall, but it certainly will not be the main class; the CS1 in Java will continue to be so throughout all of the next academic year. Currently no plan is under way to change that, though we certainly are open to evolving our courses in the long term like any other school would be. I would like to note that the state of intro at Stanford is exactly as was described to you by myself and others 10 months ago.

February 19, 2018 at 7:00 am 2 comments

Keeping the Machinery in Computing Education: Back to the Future in the Definition of CS

I’ve been excited to see this paper finally come out in CACM. Richard Connor, Quintin Cutts, and Judy Robertson are leaders in the Scotland CAS effort. Their new curriculum re-emphasizes the “computer” in computer science and computational thinking. I have bold-faced my favorite sentence in the quote below. I like how this emphasis reflects the original definition of computer science: “Computer science is the study of computers and all the phenomena surrounding them.”

We do not think there can be “computer science” without a computer. Some efforts at deep thinking about computing education seem to sidestep the fact that there is technology at the core of this subject, and an important technology at that. Computer science practitioners are concerned with making and using these powerful, general-purpose engines. To achieve this, computational thinking is essential, however, so is a deep understanding of machines and languages, and how these are used to create artifacts. In our opinion, efforts to make computer science entirely about “computational thinking” in the absence of “computers” are mistaken.

As academics, we were invited to help develop a new curriculum for computer science in Scottish schools covering ages 3–15. We proposed a single coherent discipline of computer science running from this early start through to tertiary education and beyond, similar to disciplines such as mathematics. Pupils take time to develop deep principles in those disciplines, and with appropriate support the majority of pupils make good progress. From our background in CS education research, we saw an opportunity for all children to learn valuable foundations in computing as well, no matter how far they progressed ultimately.

Source: Keeping the Machinery in Computing Education | November 2017 | Communications of the ACM

November 20, 2017 at 7:00 am 3 comments

Survey to inform the next round of Computing Curricula

The Association for Computing Machinery (ACM) and the IEEE Computer Society (IEEE-CS) with support from other organizations are producing a new curricular report titled, “Computing Curricula 2020: An Overview Report” (CC2020) in an effort to retain global currency in the computing curricula guidelines.  We reach out to you because we value your opinion in this effort. We invite you to participate in this project by responding to a brief survey found at the URL
where you can provide your comments by responding to the survey prompts.  The survey should take between 3 and 5 minutes, we do apologize for any cross postings
Thank you in advance for your time and valuable contributions to this project.
—The CC2020 Task Force

May 22, 2017 at 7:00 am Leave a comment

We have to teach where the students are: Response to “How We Teach Should Be Independent Of Who We Are Teaching”

Valerie Barr has great insights into computing education, especially with regards to diversity (e.g., see the blog post last CS Ed Week about alternative ways to view data about diversity in computing).  I like what she has to say in her most recent Blog@CACM blog post, but I think the title is somewhat misleading.

“How we teach should be independent of who we are teaching” is clearly not true.  No one would argue for teaching Linux kernel developing via all day long bootcamps in C to middle school students.  Few people use CS Unplugged with machine learning graduate students. What Valerie is explicitly addressing in her blog post is an issue called essentialism.

As we continue efforts to diversify computing, we cannot afford to paint any group in a monochromatic way.  We have to embrace the richness of today’s student population by making what we teach meaningful and relevant to them.  There are women who want to geek out about hard-core tech, and there are men who care deeply about computing for the social good.  There are students of all genders and ethnic and racial backgrounds who will be happy with an old-fashioned lecture, and those who will thrive on active learning with examples drawn from a range of cultures and application areas. Many students will be motivated by knowing how the techniques and subject matter they’re learning fit into their future workplace or life goals.

Source: How We Teach Should Be Independent Of Who We Are Teaching | blog@CACM | Communications of the ACM

Here’s a definition of essentialism (from the Geek Feminism Wiki):

The concept of Essentialism states that there are innate, essential differences between men and women. That is, we are born with certain traits. This is often used as an explanation for why there are so few women in science and technology.

In contrast, the critical issue is who is in your classroom, what do they know, and what are their motivations. As How People Learn describes it:

There is a good deal of evidence that learning is enhanced when teachers pay attention to the knowledge and beliefs that learners bring to a learning task, use this knowledge as a starting point for new instruction, and monitor students’ changing conceptions as instruction proceeds.

This is hard to do. We can’t redesign every class for each new student population. What I think Valerie is admonishing us to do is to actually check and not assume certain interests and motivations because of the demographics of the students. When we were developing Media Computation, we did focus groups with students to get their feedback on our developing designs. We surveyed the students to get a sense of what they were interested in and what motivated them. Great work like Unlocking the Clubhouse suggested our starting point, but we did not assume that the majority-female class would have stereotypical responses. We checked with our student population, and we provided different kinds of media interactions to attract different kinds of students within our population.

It would be best if we could provide educational opportunities that meet each student’s needs individually. Short of that, we can design for the students who enter our classrooms, not for the stereotypes that we might expect.

October 24, 2016 at 7:36 am Leave a comment

Older Posts

Recent Posts

June 2018
« May    


Blog Stats

  • 1,519,619 hits

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 5,276 other followers

CS Teaching Tips