$1,000,000,000 and 1 bit

I blogged a while back about the videos that our first year students have made, when we'd asked them to illustrate a measure with appropriate "killer" examples from computing. The two that scored highest in the eyes of the students were these.

First we have $1,000,000,000 ... by Daniela, John, Arben, Alan and Rhys.

Next we have 1 bit ... by Loren, Conor, Jack and Andy.

I hope that you enjoy them as much as we did ...

Unanticipated impact …

The latest incarnation of research evaluation in the UK, REF 2014, has taken the radical step of assessing the impact of research, roughly interpreted as "the effects that the work has had beyond academia" (that's my paraphrase, you can get chapter and verse at the REF website). I call it radical because it's untried - apart from a pilot -  and counts for 20% of the overall assessment, which you could identify with 20% of the money that's begin allocated on the basis of the results of the REF.

Whatever misgivings I might have about the mechanism, it's interesting to try and find out what effect your own work has had, and so we've been looking at what impact Wrangler has had since the project to build this refactoring tool for Erlang began in 2005.

The development of Wrangler was first funded by EPSRC, and then the EU's Seventh Framework Programme (FP7) in the ProTest and Release projects. This kind of European project encourages industrial / academic crossover and so one level of impact comes from Wrangler being used in industrial collaborators in these projects, including Ericsson, Quviq and LambdaStream. Moreover, some of them continue to use and develop the system after the end of the project.

What's fascinating is to see the effect of making the project open source and putting it on github, a community collaboration site. This means that anyone can contribute to the project, rather than it being restricted to the project team. Github provides a great set of tools for visualising what's happening on your project, and for Wrangler the best seem to be the Network Graph, showing all the branches, commits and merges:

and the impact analysis, showing the impact of what individuals have contributed:






which together show us that we've had a collection of contributors, some of whom we know - for example adapting the tool to work with other tools - and others who have pitched in to help to add what they needed - e.g. updating the system to support a parallel make. So, opening up the system in this case seems pretty clearly to have added to its overall impact, and take up, and so we've got some evidence to provide as a part of the REF submission …

[One thing that it seems harder to find out in github is the number of downloads, but it looks like the github API provides an answer … more on that anon.]

"Professionalism" and "professionalism"

One of the things we worry about in university Computer Science departments is how to encourage our students to have a professional attitude to what they do. At Kent we're lucky in having some 70% of our students follow a one year sandwich placement between their second and final years, as well as offering them a chance to work as a consultant in the Kent IT Clinic in their final year. However, we'd like to start inculcating a professional attitude right from the start, and we're trying that this year in our "People and Computing" module which covers estimation, communication, group working and argumentation as well as more traditional topics. That's where the videos I was talking about in an earlier post came from too.

At the same time, I sit on the BCS Professionalism Board, which has oversight of the formal professional framework that the BCS supports, not only as a member organisation of the Engineering Council UK, but also in its own right with CITP (Chartered IT Professional) status. The BCS is looking at how it can engage young professionals, including recent graduates of degrees accredited by the organisation, as well as students at university. The aim here is to encourage these young people to become chartered members of the organisation, through CITP, CEng or CSci.

So, we have two agendas, which I'll characterise as "professionalism with a small 'p'" and "Professionalism with a capital 'P'". On the face of it the two look as though they're very different; the challenge is to make them work together. The "small p" challenge is to engage the intellect and interest of the students … something that Anthony Finkelstein has made a case for very clearly already … and this is something that academics should be able to do. But there's more that can be done here, and that's to put students in touch with people at other places in the pipeline.

My experience is that BCS branch members are happy to work with others interested in computing. A specific example from the Kent Branch is that branch members have been involved with mentoring school groups in a heat of the FIRST Lego League run at the University of Kent, as well as acting as judges. Surely we can build on this willingness to get involved to build links between local branch members and students by, for example, mentoring student project groups, or other activities.

What about the young professionals? I suspect that a similar approach would be the right thing here too. The BCS has strong … and very fruitful … links with corporate bodies, but not with SMEs. Paradoxically, the corporate sector is one where companies themselves are best able to support their young employees, whereas the SME sector cannot. So, is there an untapped opportunity in the BCS supporting young professionals in the SME sector, through mentoring, training and so on. In my experience, the managers of startups and other SMEs would be very appreciative of this … they don't have the resources to do it themselves, but by the same token have staff who would most benefit from this input.

To try to pull the arguments together, maybe a key approach is to encourage mentoring by young people of young people. For the mentors it develops a professional skill, for the mentees, it helped their development. And, with this in place, the professionals "with a small p" can be encouraged to become "Professionals with a capital P".

Animating Multicore Erlang

As a part of the RELEASE project we've been looking at how to visualise Erlang computations on multicore systems. We've started by extending the Percept tool to Percept2, and you can see a presentation about that, from the Erlang Factory Lite in London here.

We're beginning to look at how we can present real-time results, and as a half-way house we've been experimenting with animating computations. We've made a video that animates run-queue lengths and process migrations for a computation on a 24 core machine (well 12 cores with hyper-threading, in fact). Any comments or suggestions that you have would be very welcome.

Making Videos

In our first year course on “People and Computers”, Sally Fincher and I asked our students to make a set of videos that illustrate the range of units in computer science, including measures of charge, data, distance, frequency, money, power and time, ranging from the tiny (for example 1 nanosecond) to the huge (e.g. 1 exabyte). The idea of this was to build a body of reference points to give students “scaffolding” for the work that they will do in the rest of the course, but we also wanted to encourage their creativity in communicating ideas this way (as well as in more traditional ways like essays). The videos were "low fi", recorded on smartphones or equivalent: we weren't looking for HD quality, but rather inventiveness and style.

Well, we've got the results now, and we were really pleased with them. What struck me was how varied the videos are (we have about thirty of them, produced by groups of three or four), but each has something interesting to say. What approaches did people use? One strategy was to approach the subject historically, giving the history of the inventor of an idea as well as the idea itself, and one ingenious group had one member impersonating the inventor! Taking a historical view allows comparisons with the (recent, or not so recent) past, and that underlines just how quickly computing evolves.

Another line was in comparisons, or analogies. Some were arresting … measuring data by the number of BluRay disks that would be needed to hold it, and the equivalent weight in baby elephants … the weight of iPad that could be bought for 1p … how many hamsters running in wheels it would take to power Google … . Other presentations brought up unfamiliar computing facts: the power consumption of a sleeping laptop … the rate of spread of the I♡U virus … MB versus “advertising” MB.

We saw some nice animations: using walking, running and skateboarding - or running different distances - to illustrate different rates of data transmission, as well as an animation of Wireshark. A number of groups used (sped up) drawing by hand to get ideas across. Some groups introduced themselves, while others remained behind camera commentating, or even using speech synthesis … quite a few had cheesy soundtrack music.

What were some of the memorable images and ideas? Personally I'll remember the “if a pea is one bit, then the peas in a pod are a byte”, you can get 170 Mb of data storage for 1p, and a description of how much data is in the video we're watching (script and image). We'll find out the most popular among the students this time next week, and I hope to post them on YouTube after that.

Going to a conference …

You never know who you're going to meet when you go to a conference. My colleague Peter Rodgers works on information display using Euler diagrams - intelligent Venn diagrams, if you like - and conferences often remind me of this. Contacts and colleagues inhabit overlapping circles (or ellipses?), and today was no exception. I talked to people at the Erlang Factory in London whose overlap is

• Haskell: enthusiasts who have also come to an Erlang meeting;
• Student placements: from a company who used to take placement students from Kent;
• Research: can we do some work together? can they provide a case study?
• Intern: Purdue engineering student visiting the UK as an intern;
• Colleagues: Roberto Aloi, who worked on the E-learning KTP and now is working on the RELEASE project, and Francesco, co-author …
• Friends: I've been around the functional programming community for a while

While we can maintain existing relationships online, there's nothing yet to replace meeting someone face to face, though it may well happen, through global warming if nothing else.

At the Erlang Factory …

It's always enjoyable going to a conference to talk about the research work that you're doing. I'm at the Erlang Factory Lite in London today, which is taking place at the Google campus in central London. The Erlang Factories are interesting because they are primarily focussed on practitioners, and have managed to build a very supportive community around putting the Erlang language to work in a variety of projects. I'm just listening to a talk by Cyan Technologies on using Erlang within an RF smart metering system deployed in India, and hearing about how Erlang is used. Finishing off now talking about how Cyan technology will support the burgeoning area of M2M (machine to machine) … and they are recruiting!

As far as the my talk went, I was talking about the Percept2 tool that's being built by Huiqing Li and me to profile Erlang systems, particularly those being deployed on multicore. This work is part of the RELEASE project, funded by the European Commission. In RELEASE we're in the process of developing Erlang to be used in a scalable way in distributed heterogenous multicore systems.

This is the first time I've talked about this, and we got a set of very good questions from the audience:

• how scalable is what you do?
• can you attach / detach Percept2 to/from a running system?
• how is migration between schedulers related to the degree of parallelism within a system? …cool research question!

So, we've got good ideas for what to do next, plus a research challenge. That's the great thing about research … in the end it's a collaborative thing. Hopefully, too, we've also made some links with people who want to try our stuff out "in anger".

Now time to listen to Ian Barber from Google on linking Google APIs and Erlang …

Starting a research project …

We're one month into the Prowess research project, which follows on from ProTest in looking at property-based testing and web services. At Kent we're looking at a number of things, some coming out of our work on Wrangler, a tool to help people write refactorings for Erlang programs, and others building on work with Quviq and Sheffield University on extracting properties from existing artefacts, like test sets.

Starting a project is a mixture of anticipation and apprehension. It's exciting to have got the go ahead for work that we planned about a year ago, and to be working with a consortium which brings together some Protesters and some new partners. There's apprehension in working out how precisely we'll do what we said we'd do according to plan: can we manage N person-months on work package M at site X? After an afternoon in Brussels a couple of weeks ago, the answer is that yes, we can.

What are we going to be doing at Kent? We'll be extending Wrangler to make sure that it supports refactoring of property-based testing for web services, so that will include working with state-machine models as well as properties. To do this we'll use the extension facilities that we've built into Wrangler, and reported in our paper Let's make refactoring tools user extensible! After a really useful visit by Ramsay Taylor from Sheffield last week, we realise that we'll also be able to use these facilities in supporting mutation testing for Erlang, since our template language is just right for expressing mutations  to programs. Because it's a proper language it's going to be particularly useful for expressing more complicated transformations such as higher-order mutations.

We're also looking at property extraction, building on existing work to extract machines from test suites written in EUnit, the test framework for Erlang. To help with that we're appointing a researcher to join the team: the job is advertised here and closes on Thursday …

The Kent IT Clinic

One of the things that many computer science departments struggle with is how to teach the practical aspects of being a professional computer scientist. At Kent we're very successful in running schemes with a year in industry, and typically more than two thirds of our students take a year out between their second and final years with us. They come back transformed, understanding how the principles that we teach them work out in "the real world" as well as having much sharper practical skills, in e.g. time management. Putting these two together it's no surprise that they have a six or seven percentage point advantage on average over the students who haven't taken a year out. A number of other CS departments have sandwich programmes like this, and they all report a similar effect.

Kent has something much more distinctive to offer, too. The Kent IT Clinic (KITC), founded in 2004 and based in the School of Computing at the University of Kent, offers IT consultancy services to companies local to the university’s campuses in Canterbury and Chatham. The industrial landscape in east Kent is made up of SMEs (and indeed micro businesses) and public bodies, and so the majority of the KITC’s clients are SMEs wanting IT services to support their businesses, rather than IT-focussed companies.

The novelty of the KITC is that the consultants are students in the final year of their undergraduate programme or the MSc programme in IT Consultancy. Students in the clinic are mentored in their work by an experienced consultant who takes the role of coordinator of the KITC, and the money received by the KITC in payment for its work goes towards paying the salary of the coordinator, as does a proportion of the students’ fees.

Students are not paid for their work; rather they receive payment in academic credit towards their degree. On setting up the clinic it was anticipated that students would also be able to work in the clinic for payment, but under this model KITC work competed with their credit-bearing work, and commitment to the clinic tailed off as the assessment load grew. The coordinator is responsible for the business side of the clinic, and academic supervision and assessment is separate.

Some of the students in the KITC have undertaken a one year sandwich placement, but others have not. Both groups of students gain from their KITC time, since the experience and skills gained there are complementary to the traditional industrial placement.

• The students on sandwich placements tend to be ‘small cogs in large machines’, working in a managed environment in a team alongside more experienced permanent staff; by contrast the students in the KITC are ‘large cogs in a small machine’ working alongside in peers from the same background in a substantially smaller, less-managed, operation.
• Sandwich students will often work on a single project during their year’s placement; in the KITC students will work on a variety of projects chosen so that together they satisfy the learning outcomes for appropriate module.
• Projects are typically supported by a team of students who need to be self-managing; indeed projects can be somewhat more complex, calling on a delivery group as well as an internal systems team, for instance.
• The group of students working on a project will get experience of the complete life-cycle of the project, from inception through costing and estimation to delivery, deployment and maintenance. 
• The costing and estimation prove to be particularly challenging for students, since projects tend to differ from each other to the extent that existing data is of little use; on the other hand previous projects are presented as case studies within the taught modules that support the KITC.  
• The students gain more exposure to the customer than in a larger organisation. They need to negotiate requirements and costs, and deliver to the customer’s satisfaction: students have learned that this can be somewhat capricious!

A number of challenges have been touched on above; the other principal challenges are discussed now.

• Business demand is constant, but the presence of students is anything but. A typical undergraduate can spend the period October – March in the KITC, while MSc students are able to devote substantial time during May – August. Students will be part of the clinic for one academic year only.
• Some months are not covered, nor are (substantial parts of) undergraduate vacations. It is therefore vital to manage the pace of delivery that the KITC can achieve.
• Students are only in the clinic part-time (typically 10 hours per week during term time) and so it is crucial to manage customer expectations of what they can expect of consultants, e.g. in providing out of hours service.
• The tunover of students brings its own problems. It is not unusual for a client to want maintenance or extension of a project delivered by a previous cohort; it is at this point that the quality of the documentation and code is really put to the test. Similarly, there is a tendancy to over-engineer internal systems, with consequent handover problems.
• Because the KITC is formally part of the university rather than an autonomous entity, students need to understand ‘professional’ aspects of delivering consulting, such as writing contracts, indemnity insurance and so forth. The School of Computing has benn lucky in the support that it has received in this regard from staff from Kent Innovation and Enterprise, the university’s industrial liaison arm. 

A thriving SME – which is what the KITC is – needs a healthy pipeline of work: some leads forthcoming, some work signed up, some in development and some in delivery. Ensuring this within a small organisation is tricky, and it is particularly problematic with the varying levels of student resource just discussed.

• Work has come in through a variety of routes: through KIE, word of mouth, repeat business and partnerships with other consultancies.
• Being clear about what is possible for the KITC and what is not is a difficult call: some of the most successful projects it has undertaken could have been seen as the most risky too, for instance.
• Ensuring the KITC has the expertise in place is also a challenge. Students will not necessasily have all the skills at their fingertips, but in some cases successful projects have been delivered on the back of students learning as they work. An expertise database is also valuable, but vulnerable to the students’ differing ability to self-assess.

Still, whatever the ups and downs, the KITC has been a fantastic learning experience for students and staff alike over the last eight years, and has given some two hundred students a chance to see how what they learn in the lecture room translates into business.