We finished the last paper session of Latice yesterday with our presentation on our work in understanding how students conceptualise software design. What motivated this work was our restructure of our first year curriculum – we have changed the way that we teach to include much more focus on open ended questions and student-led problem solving in collaborative workshops. One aspect of that was that it has become much more relevant to talk to students about the need for software design.
At the same time our students are reluctant to spend time of software designs, but instead want to rush straight to coding.
In our paper, we analysed student descriptions of their software process throughout the final course in our introductory programming sequence. We had asked them to talk about what their software process was, how it had changed, and how they intended to change it. We also asked them to draw diagrams of their software process. Our aim was to get a better understanding of how students think about the software development process and software design as they are learning how to program. With this information, we feel that we might be better placed to articulate successful strategies to new students, as well as thinking about good ways to structure our courses to explicit prompt students to developed better models of what software design is.
In our analysis we use two coding frameworks – one based on identifying self-regulated learning behaviours (Zimmerman) and one using a neo-Piagetian model of intellectual development. We coded the 200+ pages of student reflections according to these two coding frameworks to try to get a better, richer understanding of how students thought about their learning in software development.
Piaget describes a model of intellectual development for children according to age related stages – Pre operational, concrete operational and formal operational, the most advanced stage with formal reasoning and abstract conceptualisation. Neo-Piagetian models rethink this work for adult learners, identifying that these stages are not age related but that are the stages that all learners go through at any age when learning concepts within a new context.
I’ll post a link to the paper when it gets published online, but the basic idea of what we found was that students exhibited a range of understanding software design from pre operational through to formal operational. What characterised pre operational was the idea of design as artefact rather than process – students did not see the benefit of software design to their coding or testing, but instead viewed it as something that was produced as part of their process. Importantly, they were quite happy to produce the design after the code – it didn’t matter as there was no connection!
Pre operational descriptions of how to improve their software process were heavily linked to self regulated learning behaviours and magical thinking – if I started earlier I would be better, associated with better time management, study habits etc. They did not articulate anything that was specific to software development.
Concrete operational behaviours moved to viewing design as a process, but one that led to a sequence of activities, I.e. you do your design, then your code development and then your testing. Only then might you revisit your design if there were problems. Students tended to approach their design from their recent experiences, so if they had used a particular data structure recently or they had used a specific searching algorithm last time they developed a program, then they would do the same thing.
Formal operational behaviours were the most advanced and complex, understanding that design is both a process and an artefact, but with the importance placed on design. They talked about design as an interactive process of research, prototyping and experimentation, which then led to code development and testing, with the ability to revisit the design process at any point. The artefact was just a way of encapsulating their thoughts at any point in time. What was interesting is that they were able to articulate improvement strategies that embedded software design with self regulated learning – the design process had become embedded in how they approached software development problems.
Perhaps the most interesting thing about this presentation was the discussion at the end. Our audience included both engineers and computer scientists. Roger Hadgraft made a very interesting comment about the idea of teaching our students how to use basic components, rather than being so creative and designing everything again. But this goes against the way that we view and teach computer science – creativity, design and the need to understand fundamental ideas deeply is so important to a computer scientist. But is it?
Is this where we see the fundamental difference between engineering and computer science – an engineering approach would teach our students about a range of existing algorithms, data structures and components, teaching them when to choose one over the other, and how to compose them according to well defined patterns. In computer science, though, we start with open design and creativity – even more so with more modern curricula that is student-centred and problem/project based. What is the advantage of doing things this way? We lack structure and process, certainly – and we try to shoehorn that in at later stages of learning. But what do we gain? I think what is crucial here is the ability to solve problems that we have not thought about using solutions that we have never seen before. Our students cannot approach problems using just patterns and established components. They need to build new languages, new approaches and new structures to solve problems in creative ways – the basic building blocks of our discipline do change as we are able to create new models and understanding to cope with extremes of data, scale and new technology.
Is this enough to justify teaching all computer scientists in this way? Should we be rethinking software engineering to adopt some of the more process driven, structured, systems engineering approaches?