I have been recently told by Computing teachers that the new benchmarks for the subject are problematic in certain respects; leaving aside the question of whether this highly specified approach is appropriate, there are issues with coherence. The following post, by Greg Michaelson, Prof of Computer Science at Heriot-Watt University explores this issue, and is part of a wider series of commentaries on the new benchmarks.
The whole world is now utterly dependent on computing based technologies for all aspects of social and economic organisation. As computer use burgeons year on year, so does the shortage of skilled computer professionals competent to build and maintain the resilient and sustainable systems we have come to take for granted.
Thus, it is both baffling and dispiriting that Scottish Computing education seems to have been in a near permanent state of crisis these last few years, most markedly in secondary schools. The numbers of schools offering Computing has fallen, Computing teaching posts lie vacant, the numbers of students taking SQA qualifications in Computing is declining, and Computing teacher training places remain unfilled as graduates can command better salaries elsewhere.
The roots of this malaise are complex and well rehearsed, in a tiresome multi-dimensional cycle of blame involving government, local authorities, higher education and employers. Nonetheless, there has been broad agreement across the sector that the Curriculum for Excellence (CfE) in Computing has not met the needs of any stakeholders, most markedly Scotland’s school children. In particular, it is characterised by an inadequate separation between broad ICT skills, which are essential for all citizens, and Computer Science, an academic discipline in its own right, concerned with all aspects of computation, with programming at its heart.
Thus, I think that the draft revision to the Computing Science BGE Experiences and Outcomes (Es and Os) is to be welcomed. Its authors have clearly listened to the critics of the status quo, in particular taking seriously the forceful and detailed proposals of an independent team of leading Scottish academics and practitioners.
First of all, the Es and Os have been separated into three well characterised significant aspects of learning (SALs): “Understanding the world through computational thinking”, “Understanding and analysing computing technology”, and “Designing, building and testing computing solutions”. It is particularly pleasing that Computational Thinking (CT) is fore grounded in its own SAL, as the key problem solving approach. It is also pleasing that the underpinning technologies, both hardware and software, have equal weight to CT and programming. This emphasis on computing leading to mechanical, repeatable, predictable procedures is, I think, central to understanding programming which is usually practiced at levels far abstracted from the underlying silicon.
Secondly, the SALS are well sequenced. Each starts at the Early stage with practical activity grounded in the students’ own experiences. These are used to draw out increasingly structured, differentiated and abstracted concerns as the SALs progress.
Thirdly, the SALs are strongly complementary, especially in the core stream leading to programming competences. Their formulation offers sustained opportunities for integrative learning activities throughout all stages, linking exploring a problem in the abstract to tease out possible solutions, to their practical realisations in some concrete programming notation, on a concrete platform.
The SALS are well served by the accompanying Benchmarks: Technologies document, which provides considerable concrete guidance for evidence based assessment of competences. It also fleshes out the more general nature of the Es and Os. In particular, the synergies across SALs are well laid out.
However, the devil is in the detail. My main concern is that CT is a new and ill defined discipline, remaining different things to different people. For example, the early stages follow Papert’s pedagogy of structured bricolage in a microworld, where the later stages draw on contemporary characterisations of CT as iterative activities of decomposition, pattern identification, abstraction and algorithm construction.
I think that it is vital to enunciate an explicit pedagogy of CT, as a well defined discipline that all Computing Science teachers can deploy consistently. Scotland is lucky to enjoy considerable research into and application of CT and I hope that this can be integrated in elaborating a unitary approach, backed by systematic support and exemplification material.
My second concern is that, while there is a strong emphasis on procedural and computational aspects of problem solving, little consideration is given to informational aspects. I think that teasing out the information structures that underlie problem domains is an essential component of CT. Indeed, exploring the information relevant to solving a problem offers excellent opportunities for pre-algorithmic CT, which may be easily based in motivational everyday activities.
Here, I can’t help feeling that an integrative cross-curricula opportunity has been lost. The separate Digital Literacy area focuses on information and problem solving in its “Using digital products and services in a variety of contexts to achieve a purposeful outcome” SAL, in particular at stage two. Indeed, the whole of this SAL would not be out of place in the Computing Science area.
Thirdly, I think that there are pedagogical and practical problems in moving from a block-based language at the first stage to a technical language at the second. This is a transition where students could easily come adrift and will need careful finessing.
Blocks based languages, like Scratch or Snap!, are programmed by assembling graphical elements representing entities and operations to solve problems, typically in a simple microworld of moving and interacting avatars. They are an excellent starting point for exploring basic concepts of sequence and repetition. However, they tend to offer impoverished general programming constructs and are unsuitable for constructing new microworlds, the ultimate goal of programming.
In contrast, technical languages are textually based. Choices are often constrained subsets of industrial languages, like Python or Java, which enable steady scaling up to full strength programming. However, getting the same effects as those achieved easily in blocks based languages requires considerable skill in programming to configure components from code libraries.
Fourthly, there is no recognition that the activities of constructing web pages and databases at stages three and four also require CT based problem solving and programming, so another integrative opportunity may be lost.
Finally, there is considerable overlap between stage four and the National 5 curricula. No doubt this will be revisited once the new BGE beds in, but it certainly is worth considering soon.
I think that these limitations are again reflected in the Benchmarks: Technologies document, in particular an overemphasis on procedural and structural aspects of CT at the expense of information. I find it sad that the sole data type to be explored by stage four is the number, which will lead to a repetition of dreary old problem solving based around arithmetic and counting.
Aspects of the Benchmarks: Technologies document seem problematic as a basis for assessment. While benchmarks for the core CT/programming competences have a strong emphasis on seeking evidence for the understanding of concepts, the other competences depend far too much on rote learning of “facts” about computing. Furthermore, the web and database benchmarks are extremely vague, defined simply as building something, without having spelled out what might constitute evidence for competence from the crucial design, usability or performance perspectives.
Nonetheless, despite all my carping, I think that the new Computing Science BGE is a substantial improvement on CfE mark one, and that this refreshing reboot deserves to flourish.