SIGCSE, Why Can’t I Implement Everything?

I was going to blog about Mike Richards’ excellent paper on ubicomp, but Katrina did a much better job so I recommend that you go and look over there.

My observation on this session are more feeling based, in that I’ve seen many things at this conference and almost every time, I’ve wanted to tell more people about it, or adopt the mechanism. As Katrina said to me, when we were discussing it over lunch, you can’t do everything because we only have so many people and not every idea has to be implemented at every University.

But it’s such a shame! I want small home-rolled mobile computing platforms and fascinating programming environments! Everything good I saw, I want to bring home and share with people. However, the hard part is that I want them to be as fascinated and as excited as I am – and they’re getting it from me second-hand.

The other things that I have to remember is that whatever we do, we have to commit to and do well, we can’t just bring stuff in, try it and throw it away in case there’s a possibility of our ad-hoc approach hurting our students. We have to work out what we want to improve, measure it, try the change and then measure it again to see what has changed.

You’ll see a few more SIGCSE posts, because there’s still some very interesting things to report and comment on, but an apparent movement away from the content here isn’t a sign that I’ve stopped thinking about – it’s a sign that I’m thinking about which bits I can implement and which bits I have to put into the ‘long term’ box to bring up at a strategy level down the track.

I’ve met a lot of great people and heard many wonderful things – thanks to everyone at SIGCSE!


SIGCSE, Birds of a Feather (BOF) Session “eTextbooks”

My blogging of these events is getting later and later but another BOF session from Thursday night, hosted by Professor Cliff Schaffer from Virginia Tech. As always, my words may not quite match those of noted speakers.

Overall, a really thought-provoking panel – we all want to write but we ant to get all of the new features, without necessarily really knowing what the features available are or what the cost will be. The fear of wasting time is a constant spectre over the eBooks market. If I make it, I want it to be useful and feature-rich for some time.

What does the term eText even mean? Is it a type of text, the platform, the concept – some intersection? The virtues are obvious: portability, additional features like hypertext and search – but is this it? What are the educational benefits?

Cliff’s main idea was that, for our educational purposes, eBooks support interactivity and, hence assessment. There are projects like OpenDSA, a data structures and algorithms course in the creative commons. They’ve got content, texts, visualisations and assessment. Once a student has finished, they appear to be confident that they have understood the material.

Looking at Khan Academy it’s easy to focus on the videos, when the assessment exercises and awards system is an equally important part. But this is for Maths which is (notionally) easier to generate problem variations for and assess the result, to allow exercise in variations.

When students interact correctly with this progress determination activities, they answer the question, get told of their mark and given feedback and can then go again. Why do we mean by interactivity? (NF note, I’ll blog on this some more, later.)

There are a lot of solutions in this space, including algorithm simulation environment – how can we go beyond the textbook? Do we need to abandon the idea of the textbook as a closed container – does it make any sense any more?

The Open University in the UK has split their material between paper and electronic – electronic because of all the features and paper because students feel ripped off without a paper copy! The electronic materials have three levels of response to assessment-based interaction: firstly mark and just note where errors occurred, on the second pass, mark and suggest materials, on the third pass, if still under performing, direct student to read the material again. This is a bespoke system, producing Flash, but they hope to move to HTML5 at some stage.

Other tools mentioned included CTAT (Cognitive Tutoring Authoring Tools), AlgoViz and the amazing interactive textbook system written in Python, thinkcspy.appspot.com. If we’re going to have systems like Khan Academy, we need them to decomposable and re-usable but it would be nice if their grading system (badges) could work with us.

On the thinkcspy.appspot.com site, Brad and David’s book (Luther college), customised by Christine Alvarado, contains mid-term grades, log files and then end of term survey. CodeLens, visualisation was most correlated with results. However, outside of class time, students did not use most of interactive elements. The night before a test they flipped through the book. To learn this content, they have to change behaviour. Had assessment items already built in to drive knowledge boundary forward but students chose not to engage with the book.

Mark mentioned a new NSF project in October – building CS books for HS students to allow them to learn CS. Can’t use apprenticeship model because HS students don’t have time to mentor or be mentored because of an already full curriculum. The curse of outreach is that we have to take the time to produce and try to jam this into a heavily prescribed and full curriculum, to interest students in something – we need a mechanism that people will consult outside but it’s obvious that people won’t (according to the above).

How do we change the behaviour? All content seems to get used the most 48 hours before the mid-term! (No real surprises) There are many open questions about how students feel about reading in general and about whether we should be changing the way we write books to reflect a chunk repository, rather than a linear narrative.
Finally, a big issue was which format we should use – we need a solid, survivable format that works with publishers, authors and readers alike. HTML5 could be a start, but MathJAX is a good solid format for equations. Cay Horstmann suggests that any XML format will work.
Basically, despite these materials having been around for many years now, there are still a lot of unanswered questions. Fora like this are a start but it’s very telling that so many people had to show up to a physical venue to have a discussion about an electronic system…

SIGCSE, Birds of a Feather (BOF) Session “CS Unplugged”

Poor Tim Bell. He must think I’m stalking him. I attended the BOF session for CS Unplugged, which quickly turned into the BOF on ‘Energising your Outreach to Schools” (my words). Once again Lynn Lambert and Tim shared their experiences with CS Unplugged to help us frame what was wrong with our outreach (or the problems that we had) in order to try and fix them.

The main issues were:

  1. How do we get into the curriculum?
  2. Bad/old equipment.
  3. Creating a meaningful activity in a very short time.
  4. Persistence – how we do we stay in their minds or their environment?
  5. Priming – how we prepare them for our visit?
  6. Time – how do we fit it all in and, more importantly, how does the teacher?
CS Unplugged is a good way to address quite a few of these problems – it provides a curricular framework (1), doesn’t need equipment (2), is meaningful in a short time (3) and doesn’t take much time to carry out (6). But what about persistence and priming? The group discussed this for a while but the main message was “Train the trainer” – we need to keep investing time in teacher training to make these activities a go-to for any part of the day and a desirable activity for busy and over-worked teaching staff.
Along the way, we had a fascinating discussion of what it is that we actually do – how do we tell kids what it is that we do? As one participant says “A doctor walks in and says ‘I save lives’. We walk in and say ‘We process data.'” That’s a hard comparison but it’s a fair one.
We liked the idea that “We solve other people’s problems” and we also discussed the notion of regionalising what it is that we did, so picking out a CS focus for a given area, where the kids would see people doing it every day, or see people appreciating it every day.
Some other general notes from the session:
  • Pick the right time to come in and interact with students, when teachers are happy to have you. Teachers don’t get a reward for dealing with students at elementary level.
  • CS BIts and Bytes is a good newsletter
  • cs4fn got another mention as a good website
  • One amusing quote from a parent, after finding out what we did, was “I had no idea that CS had any application.” To our credit, nobody cried when this was told to the group.
  • Involve people in discussing useful, relevant problems and how CS is used to help: suggestions included global warming and genomic sequencing.

Overall, another fun discussion with a lot of actively concerned people trying to make things better. Please leap in for corrections if I missed something important or got something wrong. I’m also happy to edit to add credits if required. 🙂

 


Fred Brooks: Building Student Projects That Work For Us, For Them and For Their Clients

In the Thursday keynote, Professor Brooks discussed a couple of project approaches that he thought were useful, based on his extensive experience. Once again, if you’re not in ICT, don’t switch off – I’m sure that there’s something that you can use if you want to put projects into your courses. Long-term group projects are very challenging and, while you find them everywhere, that’s no guarantee that they’re being managed properly. I’ll introduce Professor Brooks points and then finish with a brief discussion on the use of projects in the curriculum.

Firstly, Brooks described a course that you might find in a computer architecture course. The key aspect of this project is that modern computer architecture is very complex and, in many ways, fully realistic general purpose machines are well beyond the scope of time and ability that we have until very late undergraduate study. Brooks works with a special-purpose unit but this drives other requirements, as we’ll see. Fred’s guidelines for this kind of project are:

  1. Have milestones with early delivery.

    Application Description
    Students must provide a detailed application description which is the most precise statement that the students can manage. A precise guess is considered better here than a vague fact, because the explicit assumption can be questioned and corrected, where handwaving may leave holes in the specification that will need to be fixed later. Students should be aware of how sensitive the application is to each assumption – this allows people to invest effort accordingly. The special-purpose nature of the architecture that they’re constructing means that the application description has to be very, very accurate or you risk building the wrong machine.

    Programming Manual (End of the first month as a draft)
    Another early deliverable is a programming manual – for a piece of software that hasn’t been written yet. Students are encouraged to put something specific down because, even if it’s wrong, it encourages thought and an early precision of thought.

  2. Then the manual is intensely critiqued – students get the chance to re-do it.
  3. The actual project is then handed in well before the final days of semester.
  4. Once again the complete project goes through a very intense critique.
  5. Students get the chance to incorporate the changes from the critique. Students will pay attention to the critique because it is criticism on a live document where they can act to improve their performance.

The next project described is a classic Software Engineering project – team-based software production using strong SE principles. This is a typical project found in CS at the University level but is time-intensive to manage and easy to get wrong. Fred shared his ideas on how it could be done well, based on running it over 22 years since 1966. Here are his thoughts:

  1. You should have real projects for real clients.

    Advertise on the web for software that can be achieved by 3-5 people during a single semester, which would be useful BUT (and it’s an important BUT) you can live without. There must be the possibility that the students can fail, which means that clients have to be ready to get nothing, after having invested meeting time throughout the project.

  2. Teams should be 3-5, ideally 4.

    With 3 people you tend to get two against one. With five, things can get too diffuse in terms of role allocation. Four is, according to Fred, just right.

  3. There should be lots of project choices, to allow teams choice and they can provide a selection of those that they want.
  4.  Teams must be allowed to fail.

    Not every team will fail, or needs to fail, but students need to know that it’s possible.

  5. Roles should be separated.

    Get clear role separations and stick to them. One will look after the schedule, using the pitchfork of motivation, obtaining resources and handling management one level up. One will be chief designer of technical content. Other jobs will be split out but it should be considered a full-time job.

  6. Get the client requirements and get them right.

    The client generally doesn’t really know what they want. You need to talk to them and refine their requirements over time. Build a prototype because it allows someone to say “That’s not what I want!” Invest time early to get these requirements right!

  7. Meet the teams weekly.

    Weekly coaching is labour intensive and is mostly made up of listening, coaching and offering suggestions – but it takes time. Meeting each week makes something happen each week. When a student explains – they are going to have to think.

  8. Early deliverable to clients, with feedback.

    Deadlines make things happen.

  9.  Get something (anything) running early.

    The joy of getting anything running is a spur to further success. It boosts morale and increases effort. Whatever you build can be simple but it should have built-in stubs or points where the extension to complexity can easily occur . You don’t want to have to completely reengineer at every iteration!

  10. Make the students present publicly.

    Software Engineers have to be able to communicate what they are doing, what they have done and what they are planning to do – to their bosses, to their clients, to their staff. It’s a vital skill in the industry.

  11. Final grade is composed of a Team Grade (relatively easy to assess) AND an Individual Grade (harder)

    Don’t multiple one by the other! If effort has been expended, some sort of mark should result. The Team Grade can come from the documentation, the presentation and an assessment of functionality – time consuming but relatively easy. The Individual Grade has to be fair to everyone and either you or the group may give a false indication of a person’s value. Have an idea of how you think everyone is going and then compare that to the group’s impression – they’ll often be the same. Fred suggested giving everyone 10 points that they allocated to everyone ELSE in the group. In his experience, these tallies usually agreed with his impression – except on the rare occasion when he had been fooled by a “mighty fast talker”

This is a pretty demanding list. How do you do tasks for people at the risk of wasting their time for six months? If failure is possible, then failure is inevitable at some stage and it’s always going to hurt to some extent. A project is going to be a deep drilling exercise and, by its nature, cannot be the only thing that students do because they’ll miss out on essential breadth. But the above suggestions will help to make sure that, when the students do go drilling, they have a reasonable chance of striking oil.


SIGCSE, Curriculum 2013 – the Strawman Cometh

It may come as a surprise to some, but the curriculum for Computer Science is regularly revised and, in recent times, we have see a new curriculum in 2001 and 2008. You can find all of this information at the CS2013 website. The 2013 revision has recently been published for the first time as a Strawman – something that you can attack and, traditionally, how we expose new things in CS to wider comment. Once everyone has hacked away at the Strawman, we examine the cuts and the weak points, patch it up, produce a new draft (the Ironman) and see how this stronger version fares against the slings and arrows of our peers.

This year, I had the chance to sit in on the steering committee panel from the ACM and IEEE-CS who had started the ball rolling. In order to produce a curriculum that is deemed (informally) to be a CS degree that meets the standards of the professional bodies, you have to have Core elements and a selection of Elective elements. Well, that was until now. Today’s big reveal, which was already known to anybody who read the earlier document released in February, was that Core was now Core Tier 1 and Core Tier 2. Instead of having 290 hours of ‘essential’ core material, we now had 163 hours of Tier 1 and up to 142 hours of Tier 2. On top of this, there’s a heap of ‘optional’ Elective elements.

So what makes up a CS degree? Well, if you use all of Tier 1 and at least 80% of Tier 2 and then fill in the cracks with Electives – that’s meeting the curriculum requirements and you have a CS degree. You’ll note however that the number of hours required for all of core has crept up by 15 hours since 2008 – this reflects the addition of new hours to reflect areas being introduced such as Information Assurance and Security, and Parallel and Distributed Computing. The curriculum does change over time but things tend to move rather than disappear. Adding things, however, requires more hours and this is always a problem – what do we take out? (A humorous suggestion was made that we ignore all other courses and ONLY teach CS. Not going to happen anytime soon.)

The depth of knowledge that is required is now described in a degenerate Bloom-derived taxonomy: knowledge (need to know what a concept means), application (can apply the concept) and evaluation (can compare/contrast/select appropriate method/strategy for different situations). My first thought, which needs review, is “Where is synthesis?” but I need to think about this – this would be the Creating step in Bloom’s revised taxonomy and it’s missing here. If it really bothers me, I’ll have to raise it as a consultative point.

We’re at an early stage of the process here, the Strawman consultation goes on for several months and then we get to attack Ironman. When I get back, I’m going to need to look across all my areas of curriculum responsibility and work out what to do – especially as my area “Net-Centric Computing” has now been changed in name and time, and split across two areas! Looks like it will be a busy few months.

Some audience members seemed to get caught up with how they could validate their curricula, which is missing the point in some respects. A country’s professional accreditation body, such as the ACS in Australia, will be a vital part of stating whether you have a CS degree or not. As one of the panelists said “To quote Pirates of the Caribbean, these are more along the lines of guidelines” and, thinking about this, it makes sense because it leaves the academic authority in the hands of the institutions while still allowing a discussion of internationally consistent framing for what it means to graduate in Computer Science.


SIGCSE, Keynote #1, Fred Brooks. (Yes, THAT Fred Brooks.)

Frederick P. Brooks, Jr is a pretty well-know figure in Computer Science. Even if you only vaguely heard of one of his most famous books “The Mythical Man Month“, you’ll know that his impact on how we think about projects, and software engineering projects in general, is significant and he’s been having this impact for several decades. He’s spent a lot of time trying to get student Software Engineering projects into a useful and effective teaching form – but don’t turn off because you think this is only about ICT. There’s a lot for everyone in what follows.

His keynote on Thursday morning was on “The Teacher’s Job is to Design Learning Experiences; not Primarily to Impart Information” and he covered a range of topics, including some general principles and a lot of exemplars. He raised the old question: why do we still lecture? He started from a discussion of teaching before printing, following the development of the printed word and into the modern big availability, teleprocessed world of today.

His main thesis is that it’s up to the teacher to design a learning experience, not just deliver information – and as this is one my maxims, I’m not going to disagree with him here!

Professor Brooks things that we should consider:

  1. Learning not teaching
  2. The student not the teacher
  3. Experience not just the written word
  4. developing skills in preference to inserting or providing information
  5. designing a learning experience, rather than just delivering a lecture

His follow-up to this, which I wish I’d thought of, is that Computer Science professionals all have to be designers, at least to a degree, so linking this with an educational design pathway is a good fit. CS people should be good at designing good CS education materials!

He argues that CS Educational content falls into four basic categories: the background information (like number systems), theory (like complexity mathematics), description of practice (How people HAVE done it) and skills for practice (how YOU WILL do it). In CS we develop a number of these skills through critiqued practice – do it, it gets critiqued and then we do it again.

He then spent some time discussing exemplars, including innovative assignments, the flipped classroom, projects and a large number of examples, which I hope to commit to another post.

Looking at this critically, it’s hard to disagree with any of the points presented except that we stayed at a fairly abstract level and, as the man himself said, he’s a radical over-simplifier. But there was a lot of very useful information that would encourage good behaviour in CS education – it’s more than just picking up a book and it’s also more than just handing out a programming assignment. Often, when people disagree with ‘ivory tower’ approaches, they don’t design the alternative any better. A poorly-designed industry-focused, project-heavy course is just as bad as a boring death0by-lecture theoretical course.

Bad design is bad design. “No design” is almost guaranteed to be bad design.

I’ll post a follow-up going in to more detail over what he said about projects some time soon because I think it’s pretty interesting.

It was a great pleasure to hear such an influential figure and, as always, it wasn’t surprising to see why he’s had so much impact – he can express himself well and, overall, it’s a good message.


Another Airport Land Speed Record: Can My Students Make Their Connections?

As I was running through San Francisco Airport last week, I was thinking many things. Among them were:

  1. Why am I running through yet another airport?
  2. How long will it be before my bad knee gives out? (Surgery last November)
  3. Is my wife still behind me?
  4. Do I ever do this to my students?

Two people running through an airport.

The reason that I was, once again, running through an airport was that delightfully evil concept – the legal connection. This is the minimum connection time estimated for your incoming and outgoing flights, through a given airport. When your travel organiser goes to make flights, they plug all of your destinations and restrictions into their computer, add some seriously manual machinations, and then receive a set of results that all meet the legal connection limits. These are connections that the airlines say are legitimate and, if you miss a flight, they will assist you in making another one. There’s only one problem with the so-called legal connection. Any variances to the schedules, caused by weather, delay in customs, late arrival of other planes, maintenance or unexpected construction in the airport, can make it hard to impossible to make your (so-called) legal connection. Hence, I run a lot in airports. I very rarely miss planes but I run past a lot of people who do – people who don’t know that there’s only one bus every 40 minutes between the international and domestic terminals. People who don’t know where the bus is or that it’s more reliable to catch a cab. People who don’t know which way to go and there isn’t enough signage to assist – Frankfurt Airport, with your sign that says ‘Terminal X this way” and a sign that points in both directions, I’m looking at you.

On this occasion, my knee held out and my wife WAS behind me, which is just as well as the hotel is booked in her name. But it really made me think about the layout and structure of STEM curricula. We set up pathways through our courses that are designed to develop knowledge and produce a graduate with the right combination of skill and knowledge. But what else do we assume? If we have provided bridging to bypass a pre-requisite, are we secretly assuming that the student will have aced the bridging or just passed the bridging? Do we introduce Boolean algebra in second year because “almost every student will have enrolled in Logic I” even though it’s not formally part of our course progression?

We can look at our programs as being legal connections, but with that comes all of the darker aspects that this entails. We’ve recently redesigned our curriculum, just in time for curriculum 2013, and part of this was removing some of the implicit assumptions and making them explicit. Providing pathways for the less-experienced. Matching expectations so that a Pass in a pre-req was sufficient for the next course – you didn’t need 60. We build giant pyramids of knowledge throughout our courses but, of course, a pyramid only works one way up and is far less stable if we don’t have all of the supports. If too many of these building blocks are assumed, and not explicit, then our legal connection is next to impossible to make. And we all know what the cost of that is.

I don’t want to run through anymore airports, and I strongly suspect that when we ask our students to do so, we lose a fair few of them on wrong turns or leave them stranded somewhere along the way, without ever making their destination.