Developing a Framework to Define K-12 CS Ed: It’s about consensus not vision

I’ve mentioned my involvement in the initial meetings for the new K-12 CS Ed framework effort (see previous blog post). This effort is now formally announced with a steering committee and a website.

CSTA, ACM, and Code.org are joining forces with more than 100 advisors within the computing community (higher ed faculty, researchers, and K-12 teachers, many of whom are also serving as writers for the framework), several states and large school districts, technology companies, and other organizations to steer a process to build a framework to help answer these questions. A steering committee initially comprised of the Computer Science Teachers Association, the Association for Computing Machinery, and Code.org will oversee this project.

Source: Announcing a New Framework to Define K-12 Computer Science Education | A Framework for K-12 Computer Science Education

Pat Yongpradit did a terrific job of organizing these initial meetings, setting the ground rules, and trying to engage as many perspectives as he could.  The overall goal of the process is described (copied from this page):

To create a high-level framework of computer science concepts and practices that will empower students to…

• be informed citizens who can critically engage in public discussion on CS-related topics

• develop as learners, users, and creators of CS knowledge and artifacts

• better understand the role of computing in the world around them

• learn, perform, and express themselves in other subjects and interests

There is a 0th item here that’s left unsaid: The goal is to create a framework that most people can agree on.  “Coherence” (i.e., “community buy-in”) was the top quality of a framework in Michael Lach’s advice to the CS Ed community (that I described here). As Cameron Wilson put it in his Facebook post about the effort, “the K-12 CS Framework is an effort to unite the community in describing what computer science every K-12 student should learn.”  It’s about uniting the community.  That’s the whole reason this process is happening.  The states want to know that they’re teaching things that are worthwhile.  Teacher certificates will get defined only what the definers know what the teachers have to teach. The curriculum developers want to know what they should be developing for.  A common framework means that you get economies of scale (e.g., a curriculum that matches the framework can be used in lots of places).

The result is that the framework is not about vision, not about what learners will need to know in the future.  Instead, it’s about the subset of CS that most people can agree to.  It’s not the best practice (because not everyone is going to agree on “best”), or the latest from research (because not everybody’s going to agree with research results).  It’s going to be a safe list.  Take a look at the developing standard (see links here), and compare it to the CSTA standards (see link here) or the CS Principles Big Ideas (see link here).  The overlap between them is pretty big.

That’s not a critique of this process.  It’s a limitation of frameworks in general.  Standards and frameworks efforts are not about defining what CS education should be.  They are a definition of the community’s standards.

The danger is that the frameworks are then accepted as the definition of the field.  There is a danger that standards can ossify a field. We end up teaching to the standard, not to the goals. (A humorous treatment of this idea can be found in this cartoon that Shriram Krishnamurthi shared — just swap “coding” for “clocks.”)  We have to keep asking what should be taught to everyone to help them meet the requirements above.

I don’t want to start nit-picking the framework, but I want to give one concrete example of something that typically gets left out because of community pressure.  Alan Perlis (who with Alan Newell and Herb Simon named the field in 1967 in Science) said that computer science was the study of process.  Why isn’t process a big idea?  Why don’t we teach about race conditions, and communication between processes, and how execution speed can increase (or decrease) when spread across multiple processes?  Programming tools like Scratch, Squeak Etoys, and App Inventor let students work with processes.  Much of the programming in robotics, Arduinos, and other low-cost hardware requires understanding of processes.  Moti Ben Ari (see here for example) and Ben Shapiro (in Blocky-Talky) are doing fascinating work trying to understand how kids think about process and how to teach them most effectively. Peter Denning, Alan Kay, and Mitchel Resnick have described how exploration of computational processes can support better student understanding of non-computational processes, e.g., biological, ants, termites, and traffic jams.  Processes are a big idea in CS (since the very beginning), can help students learn outside of computing (they’re a “powerful idea” in Papert terms), and will be what learners will work with in the future.  Why not include processes as a Big Idea?  Because we don’t teach about processes in today’s classes. There is very little about processes in the prior frameworks. The programming tools we have used to teach CS (Pascal, Java, Python) don’t make it easy to deal with threads and processes.  We’re developing frameworks based on what we have taught and not on what we should teach.  We should keep pushing on processes as a big idea, and I hope that they’ll be in a future version of the framework.

That’s the nature of frameworks.  It’s about consensus, not about vision.  That’s not a bad thing, but we should know it for what it is. We can use frameworks to build momentum, infrastructure, and community. We can’t let frameworks limit our vision of what computing education should be.  As soon as we’re done with one set of frameworks and standards, we should start on the next ones, in order to move the community to a new set of norms.