In the last year JISC seemed to disappear. They have endured an internal restructring, and big cuts (in the name of austerity, I assume), and several of my friends lost their jobs when UKOLN was closed down. The good news is that the people at UKOLN seem to have all gone one to good, interesting jobs in other parts of the sector. To find out where some of them landed, see the UKOLN-diaspora
At Southampton we have historically had more than “our fair share” of JISC money. Part of the reason for that, I think, was that we took on projects that were realistic, we ran them with the goal of producing something useful, rather than just to tick the boxes to fulfill the requirements, and that we staffed them with people who were primarily developers, rather than researchers. In the last year there’s been very little funding for projects like this, not just for us, but for the UK. This means that some very talented people have had to find jobs outside the sector. Rebuilding this skillset will take us many years even if we start now.
First they cancelled Firefly, then they cancelled Dev8D, what next? Bacon?
mmm, hyperbolicious.
Some of these impacts were not obvious in advance, and a few things occur to me in retrospect.
- Small JISC projects were like startups; most fail but a few can pay off big.
- Small JISC projects let people fail, and failing is how you learn not to fail next time. Many .ac.uk developers had the opportunity to learn their craft without being under the yoke of university central IT which by its nature is risk-adverse.
- Small JISC projects were sometimes exploited, I hear, as a way to keep paying a promising young researcher, in between the big projects. While this is an “exploit”, it may have prevented losing good young researchers who can’t afford not to be paid for 6 months between two big projects, so actually really have benefitted the sector.
Who moved my Cheese?
Those days are over. In the big review of JISC, the mood was very much against these little projects. The days of things like RedFeather getting funded are past and we need to get over that and work out how to work in the new world order, where Jisc (ne. JISC) will, I understand, be looking at bigger projects and providing services to the sector.
What we need to do is to still make sure there is still a career path from “comp-sci graduate” to “experienced innovator”. There’s a couple of ways we can do this.
Idea 1: Accept that innovation is part of the costs of running a university
First of all, universities need to realise that they need to grow this talent in-house. You can’t afford to hire people with the required talent and passion unless they have near zero experience or by sheer luck have to re-locate to your city. This is, I believe, also a very good way to get more female developers. If you can give women engineers a chance to love the subject and do cool things then they’ll love the subject and do cool things. As will the male ones. It may be that with the new approach to Jisc, university management need to wake up and realise that hiring, nurturing and retaining this talent is now something that has to be done with their own money, not JISC grants. This is going to be a difficult change because the obvious home for this is the university IT department, but the primary goal of the IT department is to provide reliable services at an affordable cost. Innovation is disruptive, and many IT managers will be spending time ensuring it doesn’t happen. I had a wonderful meeting once where I was asked by an IT manager at Southampton what best practice for university open data sites. His usual (and very reasonable) approach would be to find out what the leader(s) in the field are doing and learn from them. It was a culture shock that we *were* a leader, so were kinda making it up as we went along and learning from our mistakes.
At Southampton, I am part of the “Technical Innovation & Development” team. Not every university has one of those, and sometimes people want to sort us into our appropriate “boxes” in the normal IT structure, Networking, Databases etc, but so far that’s not happened and we’ve got enough wins under our belt that us bimbling along in a chaotic-good kinda way is now easier to justify.
One thing I don’t like, but don’t know how to change, is that we’ve started hiring people for a fixed term project. When the money runs out we may lose those staff and the insight they’ve gained into the organisation. It would be nicer to hire people and then have them work on a project, but as part of the larger team, and when that project ends they rejoin the pool rather than just leave. It would also mean they were more likely to help with other team member’s projects and vice-versa. This way it’s not their time, specifically, on the project, but the team as a whole with them being the one foucssed on it. This is not easy when the budgets for permant staff salaries are being squeezed, so I’m not sure how realistic my idea is, but it would be nicer and better.
Idea 2: Split too-big-to-fail projects, into sub projects
If we’ve taken, say, a bajillion pound grant to design and deploy a national video conferencing network, then there’s no way we can allow this project to fail. It would be a reputation disaster and harmful if it didn’t happen. However we can look at this with more agile eyes and work out what the essential parts of the project are, and make sure those are more than fully resourced, but then take lots of other features, and give them to less experienced developers, who can start gaining that vital experience, but if their part failed entirely the main project would still deliver, but with one less bullet point on the list of nifty features.
This idea is something the new Jisc can help with. I would like them to accept that you can’t, upfront, know exactly how a really big project will go, and sometimes as you go you discover opportunities which would not have been obvious up-front. The advantage of an in-house project is you can alter course, however with a funded project you often have to stick to the course you agreed because that’s what you were paid to do. That doesn’t get the best results. I’ve seen a few projects in the past that failed by succeeding. That is, they did exactly what they set out to do and ticked all the funder’s boxes, but actually learned that they should have done it a bit different but didn’t feel they could because that’s not exactly what they had been funded to do.
So what I want to see from Jisc, on these big new initiatives, is:
- Don’t write a detailed specification and make the project stick to it, allow them to negotiate adjustments as they learn the best solution.
- Get them to deliver early and often. Often the vital feedback on a project only comes after it’s been in use, and all the funding is already spent. Also, anything that’s open source should be open source from day one, not released at the end of the project.
- Allow the big project to have experimental aspects which may fail. Do not force the entire project to be risk-adverse when it isn’t part of the core functionality of the project.
Failing fast saves money. If an idea doesn’t pan-out it would be better to ditch it and try something else rather than to spend way to much time and effort on that one requirement. Often the project will be better served by cutting the loses and using the money & time saved to do two other nifty features that can actually deilver.
Cold dead eyes?
I stole this image from Rachael Berry who is an amazing artist and you should buy her work.
One of the things I’ve heard much muttering about is that Jisc doesn’t care any more. For the past two days I’ve been at Jisc Digifest, which is sort of the relaunch party after a year of internal changes. If you believed some of the stuff I’ve heard over the last year, then the new Jisc is a soulless beast that cares nothing for the developers and will chew us up and spit us out.
Nothing could be further from the truth. The biggest challenge I had in talking to Jisc staff about the difficulties of the past year is that I kept making them cry (really, and I’m so very sorry). They are very aware of how their being off the grid has distrupted our communities and care deeply about how we can make things good under the new guidelines from on high.
What we shouldn’t do is just “wait and see what they do”. What we should do is engage with them early and often to understand their new objectives, and how to best design the new system to get all the secondary benefits we can, while achieving the new goals that resulted from the review.
So please remember, whatever you think of the new policies, that Jisc staff are not your enemy. If you are angry at Jisc please direct this to their upper management, and the people who set their targets. It’s amazing that the staff have not become hardened and cynical this past year, please show them some love, they need it right now.
Looking fundable
Right now I reckon that they are going to be a bit risk adverse. They can’t afford to have any high-profile turkeys for a while. With that in mind I made sure that I had a raft of nifty work already started at data.ac.uk which they could fund-to-improve rather than fund-to-start. Equipment.data is funded by EPSRC, the rest of data.ac.uk is done partly in my own time, partly at work as 20%-style project.
I’ve been a bit shameless in pointing out to Jisc staff all the niftiness we have that could be funded to fan the sparks into a fully realised and supported services or products. I would have never thought like this in the past, but right now I share my working space with two team-members both on fixed-term contracts so, for the first time in my life, this funding-thing is very real. They are my friends and have mortgages to pay. That said, by the time they get to the end of their current contracts they’ll have a buttload of experience in open linked data for organisations and right now that’s a very rare skill that’s going to be increasingly in demand.
I can only really do this due to my position as a permanent member of innovation staff at the university. The people on fixed contracts need to (mostly) focus on what they are funded to do. I think this is going to be a sensible model for trying to gain Jisc funding; invest some time into building a proof-of-concept, or even starting a basic service as we have done. The first few iterations of an agile project. This massively reduces the risks of the money being wasted, and means that the university accepts the cost of a bit of innovation in the hope that some of it will gain funding later. It does require a good understanding of what the objectives new-Jisc has for their money, and that is something I don’t fully grok just yet; I need to see if the DigiFest keynotes can give me a bit more insight. I missed them because I was manning our booth.
Rebranding
One thing I wasn’t a big fan of was that there was a bit of a feeling of “spin” at Digifest. The festival theme was a nice idea but didn’t quite work when everything is still a little tense. Jisc are trying hard to present an image, and I’m not really buying it just yet. I want to see what they do rather than what the image they try to put out.
I didn’t have a chance to see much of the talks at the digifest, but had many very interesting conversations with interesting people. Some gave me ideas, others I gave ideas to. I only caught two talks, those from Joss Winn & Paul Walk (both Dev8D regulars). Both talks were about trying to bridge the gap between the developer and hacker mindset and university policy and management. Good stuff. Especially if I want a hope of one day rising above “Senior technicial specialist” without just giving up vi for good and becoming a people-manager.
Regeneration
Change is difficult, but I’m choosing to be optimistic until proved wrong.
So right now Jisc as an organisation have a lot to prove and some trust to re-win. I’m choosing to give them the benefit of the doubt and accept things are going to be different. I will have to let go of some of the things I liked about JISC in the past, but I’m pretty sure there will be some exciting things which they will be able to do now that they couldn’t before.
The Dev8D community is still out there, we still talk and support each other and would love the chance to run events again to grow and strengthen the community and most importantly to meet the next generation of young developers.
A final bit of good news is that the Institutional Web Management Workshop (IWMW) is un-cancelled! It’s going to be run by CETIS instead of Jisc, but it’s great that it’s survived the kerfuffle.
It is a serious problem that academic developers (or Research Software Engineers, as we call them) are stuck with successive short-term contracts. How can you expect people to invest any passion into their work if they’re always looming under the shadow of their next end of contract deadline?
Some people seem to be doing good work in bringing together research software engineers into a centralised team: the UCL Research Software Development group, led by James Hetherington, is a good example. I’d like to see groups like this at all universities.
Have to agree with you about the loss of Dev8D! There’s a much missed gap in my schedule in March nowadays.
Chris and have being talking about this off camera and I feel partly this post was inspired by my rather contentious comments on the http://data.ac.uk mailing list.
I apologise about being hard nosed and cynical but I lived off short term contracts from a range of funders including JISC for over 4 years. I was lucky enough to work with some good people and produce some great outputs (MePrints, EdShare and RedFeather to name drop a few). When funding started getting tight my friends went off into industry or struggled by on scraps of funding. I was lucky enough to subsumed by Southampton Technical Innovation and Development Team. The skills I learnt on these projects and through #Dev8D have given me a huge advantage in the central IT world. Many of these benefits are about communicating with non-technical people rather than about technology.
The short projects gave me loads of experience working with a wide range of people and technology and I worry this will be lost in the big project world of new Jisc. We ran small projects using agile methods and results were really good. Expecting to spec a whole 3 year project up front is never going to work as effectively. As Chris points out, the projects are in unknown terrain after 9 months so renegotiating the targets every 6 months is essential.
If I could offer Jisc one piece of advice it would be this: Only offer Jisc money to people with permanent contracts. Old JISC projects really validated HEI choices to casualise technical staff but as soon as the bubble burst technically able people had no contract to come back to. After all that effort growing those staff they were just released into the wild in the name of austerity. Corollary to this: don’t let Jisc projects pay consultants. It just throwing money out of the sector to nobody’s benefit (even the project in a lot of cases).
Old JISC did good things but they were unsustainable, the new Jisc will need to tackle this problem head on. I don’t want to give the new Jisc an easy ride. They have big boots to fill and if they can fill them they will do truly great things.
What a great post and I agree – we want the Jisc people and not the corporate trappings. But the conference proved to me that the entire body of the auditorium wanted this too. The talks were outstanding – each led by an outstanding Jisc person. Hopefully this will continue to be the case in their future organisation, otherwise they’ll come a bit unstuck.
Yes, agree with having room to innovate and fail. I think the success of UKOER was having freedom to play and deliver stuff that was interesting and not just measurable.
And good luck to everyone who is trying to move with the cheese or is having to run to find new cheese.
Tonight I think I’ve finally worked out how to express this best. Be nice to Jisc staff because you wouldn’t shout at a nurse because you don’t like cuts or policy changes at the NHS. The more I mulled on it, the more the nurse analogy seemed fitting.
+1 Chris, excellent analogy
Just a short note to say, thanks for these reflections. One thing I can say is that the agile method is certainly something that is being taken seriously in new projects. In the Jisc co-design pilot last year all of the projects were only 6-8 months and have an iterative , sprint like method to their developments. They were different shapes, some were more about clarifying the directions and requirements than developing the large-scale solution, although the outcomes should help inform solutions ( & indeed they are going on to do just that) – so for example Open Mirror around the repository infrastructure and the National Monograph Strategy around …errr monographs ( there’s a range of different solutions here ..space, preservation, open publishing, metrics etc). I think projects like G4HE (gateway for higher education), so one of the projects undertaken during the Jisc transition, has been agile in approach and responded to change and direction as it went …so anyway – I totally agree this is very, very important & it is one of the big lessons I have learnt in my time in this space, and some of that through developments like dev8d. The other big lesson for me in terms of successful projects/developments is the need to really engage with the users and stakeholders – that’s key – again all of the projects mentioned here have done that, some , because of where they are on the implementation path, have perhaps been more stakeholder engaged than end user, but it is again critical to any new projects. And Chris will catch up further on equipment.data …data.ac.uk; also very interested in the technical capability and talent in UK universities & colleges & wonder what the patterns are and how to best support this – technical skills and talent & the need to maintain or foster this is coming up again & again & I think has been a feature of almost all of the forums/discussions I have been party to in the last year – for students, researchers, intermediaries, research technologists, developers etc
I don’t think I ever really got to thank you in public Rachel, but if it wasn’t for you backing #Dev8D and realising us crazy developers had more than code to contribute to the overall strategic directions of Universities we never would have had realised the capability, loyalty and longevity of the developer community (NB something I’ve actively began cultivating down here once again in Australia under the tag #ResBaz). <– Maybe its time to take this Developer-Researcher community global?!
In short, as long as you are at Jisc Rachel, good things will happen. Let alone you were the one who hired most of the Jisc staff (many now in more senior leadership positions) who are all do-ers by nature and will help bridge the top-down policy with the bottom-up innovators – I have no doubt the *open innovation* Jisc community (of which many of the above and below know and love) will rise again! Watch. this. space.
Chris and fellow commentards – just to say thank you so much for your thoughtful contributions.
As a soon to be Jisc newbie (kind of, I’ve actually been working with them on and off for ~20 years) I think one of our biggest challenges is going to be about balancing the mud slinging (in the sense of ambitious projects that would advance the state of the art but will not all succeed, rather than actual mud – unless it’s AR mud in the Digital Festival context!) and what I like to think of as the JFDI work (where there is a widespread need that can be most efficiently/effectively met if we club together). We definitely need a mix of both, but that has to be a mix that funders and subscribers alike are happy with.
I’d also note that the short term contract problem is in no way limited to research software engineers, or even software developers per se. Google around “zero hours contracts” for the pathological case. It was very telling that when we surveyed UK HEIs around their plans for Research Data Management last Autumn there were great swathes of short term contracts being created – as though institutional support for RDM is something you can do once and then walk away from. As a manager at an HEI I’ve also seen the other side of the story – huge uncertainty due to the fees changes / SNCs / Adjustment / abolition of SNCs etc. University senior management have an unenviable task to try and chart a safe path through the minefield, and have been understandably wary of making long term commitments of late.
Whilst I like Patrick’s “only give project money to people with permanent contracts” idea, this creates new problems when those people become overcommitted – and you end up hiring someone new on a short term contract to pick up the overspill, who then needs mentoring by the already overcommitted person. And on it goes… In our parochial UK FE/HE context something that I think will help enormously is the new subscription model being proposed for Jisc services (core services in base subscription + menu of optional extras), which should aid the transition from project to service and give new services a great opportunity to become established and subsequently thrive.
[following a general request to move JISC-related comments from data.ac.uk mailing list]
I’ve had a generally positive experience of contributing as a developer (and relayer of Scottish Further Education requirements) to a JISC project that started off in an open interest group and grew into a UK data standard with a supporting body of work and software.
However, my involvement not greatly supported by my educational institution, even though project developments were directly applied to the benefit of our College.
I see one of the key benefits of the JISC approach was that all communications and software and samples related to the project were released under open (for example CC Attribution) licences; and as the proceedings of the project were public, and membership (of forums and so on) largely open, then contributions could be widely gathered from interested parties, each of whom might have a particular skillset or wisdom to offer.
The corresponding drawback of routine institutional development (in my experience) is that there is no open framework of intellectual property (documentation, software, expressed ideas) which would allow genuine, public collaboration at all levels (including informal “we’re working on this” or “can you see the problem with this approach” requests).
I note that there is some treatment of intellectual property by the Software Sustainability Institute which John Robinson has helpfully drawn attention to.
As well as effective collaboration, open licensing with attribution also allows:
(public) recognition for developers and contributors that can be used to build careers;
continuing work outside institutional boundaries (including reusing developments in later work, and bringing homework into the organization without it being locked).
There is a relevance to data.ac.uk there too.
The emphasis at Jisc, for the short-medium term will be on fewer, larger projects.
The issue which has still to be tackled is the extent to which our institutions (universities & colleges) recognise the value of having their own developers and start to treat them accordingly. I don’t see Jisc necessarily seeing this as a priority for them.
The SSI is putting some effort into tackling a particular case – that of the ‘researcher developer’ and David Flanders’s work in Australia is very interesting in this respect too.
My interest is in figuring out how to get the institution to invest in it developers as a valuable resource in general, with the research aspect as just one part of the whole.
Hi Paul I think the skills issue is an issue….whether it’s in house developers, research technologists, data scientists, data librarians. This is an issue on the table whether we can do something helpful and what that might be I don’t know right now. We have been engaged in some work with the EC on what has been called research technologists and this is still live. But the wider technical skills base …well as I say it’s on the table and if it is something the sector bodies we re working with wants then we’ll be addressing it. In my brief about technology and its use and application then it’s also quite possible it comes up through that. We have a toe in the water planned with Brighton university and work with developers. Anyway we’ll see. I agree with Chris institutions do need to think about this resource and whether and how to sustain it.
And therefore I agree with your final point …this needs figured out.
Excellent post Chris, and good to see you at DigiFest. Since joining Microsoft Research I was delighted to find professional software developers/engineers embedded within every research group. These “Research Software Development Engineers (RSDEs)” are prized by the organisation for turning research ideas into prototypes, and helping with technology transfers into product groups. They are critical to Microsoft Research, and recognised as such – see http://research.microsoft.com/en-us/jobs/fulltime/technical.aspx . Indeed, products like Xbox Kinect would not have shipped without them – http://www.raeng.org.uk/news/releases/shownews.htm?NewsID=658
These people are recognised by their software contributions, not research papers. They are included on research publications by the researchers, as they are core members of the team. As such, they are able to act as a critical bridge between researchers and product software development teams. They are full-time employees, alongside the researchers and program managers in MSR. As such they are able to work on a variety of projects, from small ones (incubation) to big bets.
I have spoken on this subject at a couple of events around the topic of “Research Software Engineers”, and hope it shows that industry sees this role as very important. As software becomes more central in research, education and university management, I personally hope that it is important that software engineers be better recognised in academia.
@Martin
Re: “University senior management have an unenviable task to try and chart a safe path through the minefield, and have been understandably wary of making long term commitments of late.
Whilst I like Patrick’s “only give project money to people with permanent contracts” idea, this creates new problems when those people become overcommitted – and you end up hiring someone new on a short term contract to pick up the overspill, who then needs mentoring by the already overcommitted person. And on it goes… ”
While I agree that situation is not ideal I think it is far better than offering the exciting new work to people you are going to get rid of in a years time. If you do this you are effectively punishing your staff for taking a full time contract and at the same time not adding any skills to your full time staff. This results in a culture of under-skilled and dissatisfied full time staff who don’t sound like the sort of people who are going to build the exciting and robust technical infrastructure for the university of the future.
While I lament the unfavourable task of being a university executive having to balance an easy life right now against doing right by the University you run I find it difficult to be truly sympathetic knowing these people enjoy the luxury of a 6 figure salary.