Wednesday, December 12, 2012

What makes a good plan?

Having spent quite a bit of last weekend having to write a research plan, I've gone back to the question of “what makes a good plan?”. I think there are two principles that identify the best plans … I wonder how well mine measures up?
  • You should be able to summarise it on the back of a postcard, or in a 30 second soundbite. That probably means that there are three or four key points, rather than thirteen or fourteen, or even thirty or forty.
  • The real decisions in the plan are those whose negation would be a sensible choice. So, saying that we choose to do the best possible research, or that we aim to publish in the highest quality journals, are pretty much content free … what plan would aim not to do those things?
So, how would I summarise the research plan in three points?
  • Aim to increase research funding by 30% over three years … a modest aim, but one where we could perfectly well fail if we didn't work to achieve it.
  • Set up a formal industrial panel … in the last decade or so we've dealt with industrial input on an ad hoc basis (apart from the Kent IT Clinic advisory group) … it's time to try to get more synergy with a group of stakeholders: industrialists, educators and alumni.
  • Make sure that we have enough space to house researchers, equipment and so on … this is a real problem at our Medway campus, and will harm our research unless we're able to get the space. [This is plan as negotiating tool I suppose.]
What about the negation test? Well - sadly - I've failed that a few times: “highest quality venues”, “widest possible dissemination”, etc, but at least there are some places, and particularly those mentioned in the three points above, where we're making a definite commitment to doing something rather than something else. Whether or not we're ultimately successful is something I can come back to in 2015 …

Friday, December 7, 2012

Links to make you think, part 2

In my first post on this blog I posted a list of links to twitter posts for the People and Computers course, chosen to give a context to studying computer science.

Here's the second (and final) collection of tweets, in chronological order:


Sixth week



Seventh week



Eighth week



Ninth week



Tenth week



Eleventh week

Functional Programming in 2012

This was first written for josetteorama as publicity for CUFP 2012. but I thought I would share it on here as well …

Functional programming ideas have been around longer than computers: Church’s lambda-calculus was invented in the 1930s as a way of describing computations as functions around the same time that Turing was describing what an idealised (human) “computer” could do through Turing machines. The idea of using functions as the primary means of computing fed straight into Lisp and its (LAMBDA …), ideas of procedures in Algol68, but settled into what people now call functional languages in the late 1980s, with the definition of ML, Haskell and Erlang.

Erlang – which is really a language for high-concurrency, fault-tolerant, robust systems – is based on functional ideas because it’s so much easier to write concurrent systems when every assignment is a single assignment (check out Single Assignment C too). Haskell and ML (and also OCaml, SML, …) are general purpose languages where types do much of the heavy lifting for you: types are inferred from what you write, and if you have got a program that type checks then you’ve ironed out a whole class of errors before running a single instruction.

As I’ve said, these languages were first defined more than twenty years ago, so what are the modern functional programming languages? One answer is Java, and other mainstream languages, which are taking on more and more functional features. Using immutable data is inherited from the functional world, as were Java generics. Coming soon are closures – yes, that’s right, LAMBDA in Java! So you can do functional programming in Java (and O’Reilly have recently published Functional Programming for Java Developers: Tools for Better Concurrency, Abstraction, and Agility).

But what if you want to try the real thing? A first choice is F#, which puts a functional language into the .NET framework as a first-class citizen, with internationalization, intellisense, and full integration with C# and the .NET libraries. One of the ways of getting started with F# is to use it to explore some of the library APIs, executing calls interactively. Extending Java to give a fuller functional language, as well as Erlang-style concurrency, is Scala. From Scala too, there’s access to the Java libraries, as well as execution on the JVM. Finally, it’s worth taking a look at Haskell, which is functional first, but which provides controlled access to concurrency, IO, exceptions and a wealth of open source libraries.
But, why bother, you might say? One reason is sheer curiosity: you’ll find out what all the fuss is about, and see where ideas like map-reduce come naturally out of the programming style. It also give you a different way of attacking problems: even if you’re going to be programming in Java, then a functional style might well give you a different tool to solve the problem at hand.

Another reason is to get a job (really!). How are functional languages getting used? Erlang and Scala support high-throughput message handling and web systems, and are the “secret weapon” behind applications supporting Facebook, Amazon and other systems. Haskell gets used in building domain-specific languages in security, crypto and increasingly in the financial sector, where F# is getting traction too. You’ll see a steady stream of jobs calling for Erlang, Haskell, Scala, F#, as well as for people who are happy using one of these languages and C, or Java or whatever, because functional languages often come in as a solution to part of a problem, rather than solving the whole thing.

Added December 2012: Another sign of functional programming getting traction is Simon Marlow, one of the "two Simons" supporting GHC, moving to Facebook in the new year …

Sunday, December 2, 2012

Tracking our time

The end of a busy week … one of the weeks I've had to record for the TRAC exercise that all English universities go through. When we do this we record all that we have done over the week, categorising things as teaching, teaching prep, funded research, admin etc. Although this is apparently an exercise in transparency, it's not what it seems. We record actual hours (61 in total this week: OK, that's more than usual, it's been a busy one), and then our activities are reported as percentages, deemed to come out of a 37.5 hour week.

It's no wonder the consequences of analysing these data are perverse: instead of concluding that we cross-subsidise our research from our teaching funding based on normalised data, the fact is that we do our research in the time above the 37.5 hours … free overtime, in other words. Don't get me wrong, I really enjoy this job, and it's a privilege to do many of the things that academics do,  but the TRAC exercise does a disservice to what we do.

Ok, so what did I actually do this week?

  • Announcing the winners of the BCS/CPHC Distinguished Dissertation award for 2012 at the Royal Society, and then hearing a wonderful Needham Lecture from Dino Distefano of QMUL. We had 22 submissions to this award (from among the 100s of PhDs awarded in CS in the UK each year) and it was a hard job to pick the three we chose: we weren't looking just for first-class academic work, but also having it reported in a way that it can command the widest possible audience.
  • Preparing lectures for our new first year course: one on professionalism, and another collection of case studies to discuss in tomorrow's session. Also, I do a talk on the “Disappearing Computer” to the University's Global Skills award for postgrad students, and it needed revising.
  • Spending a day interviewing for a new research position on the PROWESS project.
  • Finalised the school's submission for the pilot of the upcoming Research Evaluation Framework: Kent is piloting the process a year ahead of the actual exercise, and the deadline was noon on the 30th. 
  • Worked with colleagues on our upcoming BCS Accreditation visit.
  • Had our first interviews of students for next year. Fascinating discussions with both of them, so I do hope that they choose to come to Kent …
  • Worked with Huiqing Li, my colleague and research collaborator, on our next steps for research projects, as well as the undergraduate project group we're working with. 
  • Gave feedback on one of my colleague's research grant applications … it's looking very strong, and so he'll be submitting it soon. Two more to look at tomorrow, too.



Wednesday, November 28, 2012

$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 ...

Tuesday, November 20, 2012

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.]

Thursday, November 15, 2012

"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".