In this guest post, Ilian Todorov from the Science and Technologies Facilities Council gives us his perspective on the SSI Collaborations Workshop.
____________

This article represents my personal point of view. It is related but complementary to Dirk Gorissen’s ‘The researcher programmer, a new species?’ blog and the discussion on the ‘Scientific Software Development and Management’ group page of LinkedIn generated as an outcome of SSI’s WP12 meeting. The relation pertains to why the software engineer in academia needs recognition (definition and self-awareness in the eco-system of the UK academia as discussed in a parallel session at WP12 which I chaired).

This article exploits the relationship between the lack of funding policy for academic software within UK academia and Research Councils and the lack of career progression path and thus recognition and appreciation of research software developers within the UK academia. By all means this still represents a personal view despite some citations borrowed from the discussion on LinkedIn.

Software has become the major technique of choice for many scientists. It is often considered free though often THIS means at no cost to academia. Forgetting about commercial and non-free software, software available at no cost to academics is often considered as a free lunch. However, someone somewhere down the line paid for it. Even if it was truly open and free, stepping aside from any issues related to intellectual property and licensing, someone has put their labour in writing code instructions to implement a scientific methodology of some kind. In most cases this was the labour of a postgraduate (PG) student and/or post-doctoral (PD) researcher attempting to automate and simplify the work-flow of their research routines in the immediate future.

Well, this is how it all started in academia but evolution happens to everything including software. Some home-generated codes by dedicated academics as well as research groups’ home-grown ones have aggregated into packages and suites. Although many have failed to emerge in the open and be widely used, many are still in use. Some die out after a researcher retires or a research group ceases to exist. However, some pieces of scientific software get reborn like the Phoenix, being rewritten again and again in new ways with new or more modern versions of computer languages. This is the very ground where software development skills are discovered and trained, and scientific software developers born.

In the fight to increase the quality and quantity of research and not reinvent the wheel every time when a new PG/PD researcher joins a research group, some groups as well as whole scientific communities put efforts to generate project-based ‘community codes’. Clearly, the first generation of community code leaders had a taste for writing scientific software. By and large they were research scientists themselves who produced a lot of research but also wrote and managed software.

Of course, times have changed enormously in the last 20 years. However, for the researcher in academia one thing has remained constant – their career progression is based on research performance counted as impact of their research papers in peer-reviewed journals. More papers in higher impact journals lead to more success and recognition and better chances when applying for funding or academic jobs. In contrast, software development has diversified and become a well-defined profession with many sub-fields and computer languages. It is not surprising at all for an industry that governs our lives at home – PCs, electrical appliances, games and toys, mobile and smart devices, apps – at work and anywhere we go –databases, financial transactions in trade, GPS, traffic and goods flow control, industry etc. It has also become a discipline in its own right in higher education as informatics or computer science.

Despite the strong engagement of academic research with scientific software production, the software developer’s position in academia has often been related to that of a support scientist or lab technician role and scientific software engineering is often not considered as a discipline of its own. Of course, when one’s job or calling is to create code to facilitate scientific research they do not have the time to do all possible research they could with their creations and write papers in the domain of science their work is associated with. For creating code (deployment, testing, maintenance, continuous integration, etc.) is not the only task they do – other tasks include: software design to implement specific methodology, handle large amounts of data, utilise high performance computers (HPC) effectively, setting up websites and databases, writing database apps, writing GUIs, writing documentation, providing user support and training. Like scientists, these software engineers test their routines (hypotheses and solutions) for correctness by subjecting them to well-defined test cases. Like researchers, they keep abreast of the cutting edge of scientific methodologies in their research area in order to develop and prove them worthwhile and working. Like lecturers, they develop pedagogic skills to teach and train PG/PD researchers. Like academics, they write papers and grant proposals, as well as technical reports and manuals. However, unlike most academic researchers they keep abreast of relevant IT trends – numerical algorithms, computer languages, analysis tools and hardware – because all these are changing too quickly to be ignored. These changes may lead to poor performance of paradigms and algorithms that worked well before (bottlenecks), or novel constructs in computer language solving concepts that took a long time to engineer with older versions of the same languages, etc.

Unlike the LinkedIn discussion of Dirk Gorissen, I would argue the point that every scientific software developer is an academic researcher by heart but not every academic researcher is a scientific software developer. That often what is delivered by a scientific software developer is ‘mainly code’ (i) does not make them non-researchers, and (ii) is usually an outcome of too many requirements to satisfy and too much demand to answer for (from which they have to learn to fend off).

Doing research and scientific software development are neither mutually exclusive nor fully inclusive activities. They involve different skills as do realising research and writing grant proposals. They are thus complementary activities, but training an extra skill takes extra time and effort. Scientific software engineering skills and training are not considered as valuable as, for example, a degree in computer science and thus they are often not considered as proper and ignored by commercial software houses.

It is not the naming of ‘the new species’ that Dirk Gorissen defines as a problem but the lack of recognition and appreciation of the work, role and skill of the scientific software engineer in both academia and industry. On the one hand it is the lack of progression path in academia for scientists who devote themselves to the research software development path. On the other hand it is the lack of recognition of skill gained in academia by the commercial software houses. The lack of security of career development in academia often makes talented software developers move to industry no matter the inconvenience and cost. However, such a move has to be well-timed. Almost like obtaining a PhD, being trained to think on a more complex level may make scientists fail to obtain a commercial job if they stayed too long post-doc-ing. Being trained as both a scientist and a software engineer may indeed lead to a dead end career move. However, life does not stop and someone has to pay the bills so any job paying better than the one of a software developer in academia is better to have. However the loss of a scientific software developer to a team is usually much greater than the loss of a researcher because it is much harder to cultivate the unique combination of skills and knowledge in a person.

Until recently, software development in the UK academia has simply been viewed as an uninteresting means for achieving interesting research. Research councils have had no funding policy for software development and sustainability, which has led to disguising such development work as just research in grant proposals. As a consequence software development work has been carried out in a cash-starved environment and software engineers had to make a living migrating from one project to another and from one department to another. This has not helped academic institutions generate career progression and development paths for them and thus put scientific software engineers in a position to be looked upon as out-of-place technicians who facilitate researchers. Often when a research project stops, so does the work of maintaining the software. In many cases, development priorities focus on meeting the minimum requirements of a specific scientific research case. Usually, it is considered a low priority to invest in making software solutions more generic in a way that might appeal to other research projects to reuse them. Without other research projects as future stakeholders of a software solution, project investigators (PIs) may only rely on extending the life of their project software by extending the life of their project through grant renewals. It remains a challenge for research groups to produce reusable software assets which can last beyond the scope of any one project. Probably, the root cause of this is the way IT projects are funded in research environments. As a consequence some software projects die, e.g. GAMESS-UK, some freeze in time, e.g. SHELL, and others move overseas, e.g. GULP, leading to what I would consider as loss of irreplaceable assets – scientific software engineers and their expertise.

Of course, my view is slightly exaggerated in order to expose the root causes of the current state of software development and sustainability in academia and the limited awareness and even more limited action of the universities and research councils in the UK. The reluctance to act comes from the overly high a price to pay for proper software development and support (let alone for sustainability)the muddy clarity of IP and ownership of software solutions, and least but not last the limited understanding of how to benchmark software developers’ skills, performance and progress. Solutions and examples may need to be looked for in industry (software houses such as NAG Ltd., Wolfram Research Ltd., Scenomics Ltd., DEShow Ltd., etc.) where I am convinced that for similar-sized software development projects on each side, the funding level in academia would be at least by an order of magnitude less than in industry. It is worth pointing out the obvious fact that the poor post-doc salary is 25 to 100% less than that of the ‘professional software developer’ and that the post-doc software developer has to publish scientific papers in order to claim progression on the academic ladder.

It is more than fair to say that I have only criticised and not shown that there are changes in the UK academia and research council environments which, although do not answer the problems outlined in this article, at least address them. Indeed, some software development and service has been supported and provided by UK communities such as the CCPs, e-Minerals and programmes such as e-Science, ultimately funded by UK research councils as EPSRC, NERC and JISC. Limited funding has been provided by EPSRC (i) to application support via the CCPs; (ii) to software development support via HEA (Daresbury Laboratory); (iii) to software HPC optimisation via distributed computational and software engineering (dCSE) projects serviced by NAG Ltd. For the last (HPC) decade EPSRC has generated just one software engineering call in 2010 (which was very weakly defined). And last but not least this year (2012), EPSRC announced software development fellowships. On the university side there has also been some activity – computational science and engineering has been established as a course by EPCC and recognised as a different subject from computer science. HPC and parallel programming training courses are now widespread and regular events for PhD students in natural sciences.

Despite the ‘progress’ claimed above the situation of scientific software engineering practitioners in academia still remains pretty dire. In my opinion it has worsened by the much quicker cycles of hardware (HPC platforms including heterogeneous ones) and novel computer languages (HPC ones and extensions such as CUDA and openCL) to that of software development. The demand for software development in academia has risen but the availability of scientific software engineers has not due to bad long-term planning and succession policies for them in academia. Millions of pounds are spent annually on commodity clusters in the UK academia and still it is the computers that are considered to be the commodity rather than the software and the developers…

In this guest post, Malte Ressin from the University of West London reflects on themes raised at the SSI Collaborations Workshop, focussing on the issue of artificial intelligence…
______________

There is a Garfield comic whose three panels tell a story that goes something like this:

John [optimistic]: Wouldn’t it be great if everyday items could talk? The sink would say ‘Good morning John’, and the mirror would say ‘You’re looking splendid, John’.
 
Garfield [cynical]: I wouldn’t like that. A blown lightbulb would be like a death in the family.

Artificial intelligence and ubiquitous computing, should it ever arrive, might be just what John had in mind. Not only computers and smartphones, but also cars, refrigerators, and why not even light bulbs and deposit bottles might eventually wish us a good morning, understand us and converse with us in natural language. Regarding Garfield’s grim prediction, there could be backups. Indeed, the arrival of artificial intelligence has been described as the singularity after which all bets are off, any prediction of the future will become moot, as nobody is able to predict what will happen once ever smarter machines design ever smarter machines.
 
I agree that predictions around future developments will become difficult in the face of the achievement of “artificial intelligence” – but not due to the progression of superhuman thinking along the slope of Moore’s Law, but rather as a result of our own limited understanding of a construct that psychologists call “intelligence”. Intelligence is what the IQ test measures, anyone?
 
I wonder if what has commonly been described as the Turing test – an automaton exhibiting responses indistinguishable from human responses must be deemed intelligent – is actually a crossroads on the road to fallacy. While its elegance is captivating and its philosophical argument impeccable, the Turing test in this description really measures the appearance of human-ness, not of intelligence. The elicitation of emotional responses, and the subsequent creation of emotional attachment, should not be confused with intelligence.
 
Maybe I shouldn’t reveal this, but I find it difficult already to consistently apply the morally bad choices in Knights of the old Republic or Mass Effect. To illustrate my point, let’s just spin the tale of voice recognition and natural language processing in smartphones to its logical sequel: How am I ever going to dispose of a device that is so “intelligent” that I am unable to distinguish its responses from a human being? Is a company creating Turing test-passing devices going to be as unsuccessful as a car company manufacturing long-lasting cars?
 
Or what would we become if “ubiquitous intelligent technology” conditioned us to such a low level of empathy that we could?

In the third of our series of guest posts about the SSI Collaboration Workshop, we hear from freelance web developer Anna Powell-Smith, who shares her tips following the workshop.
_______________

I recently attended the Collaborations Workshop as a supported developer: thanks to SSI for organising a very interesting two days.

I’m a freelance web developer, and I came to the Collaborations Workshop partly to show off my Open Domesday project, the first free online copy of Domesday Book. But I also came to learn about the cutting edge of software in British academia, and observe the challenges that academics face when producing open data and open source code.

After a thought-provoking series of workshops, discussions and lightning talks, I could write a long, reflective post about the nature of programming within academia, and how to create the incentives needed for research to produce great software as well as great papers.

However, I found that the most productive discussions I had over the course of the workshop were highly practical. So I thought I would share some services that I use as a developer, and that – based on my observations over the workshop – might provide simple, tangible benefits for technically-minded academics too.

Tip 1: Sharing knowledge though QA

I use the question-answering StackOverflow day in, day out to help me code. I couldn’t be a developer without it. It struck me that many academic disciplines might like a similar community question-answering board – where users can ask questions, vote for the best answer, and award other users points for helping out.

Luckily, setting up your own system is straightforward. One option is StackExchange, the software that powers StackOverflow. StackExchange is already setting up a bunch of communities based on its software – there’s an active maths site, and proposals for others ranging from neuroinformatics to paleontology that you can support.

If you’d rather roll your own site, there’s OSQA. This is a free, open-source clone of the StackExchange software, easy for any sysadmin to set up.

Tip 2: Productivity and collaboration

Just three small, but hopefully useful, recommendations:

• If This Then That lets you glue web services together. Say you want to post your group’s Twitter updates automatically to Facebook: it can do that. Or get an email or SMS update whenever an RSS feed updates: it can do that too. It’s simple and brilliant.
• People think GitHub is for managing code, which it is, but you can use its issue-tracker to manage any kind of collaborative project, not just software. Try Unfuddle or Sifter.
• Doodle helps organise meetings at a time to suit everyone. Do not underestimate its power.

Tip 3: Becoming a coder

Workshop participants talked about the importance of teaching everyone to code. (Hear hear!) I recommend the white-hot Codecademy, which offers a series of browser-based JavaScript lessons. I also like CodeSchool for more experienced developers.

If you already have HTML and CSS skills but struggle to get sites looking professional, the new and very exciting Twitter Bootstrap is your friend. It’s a collection of flexible, adaptable design elements that massively simplify the process of putting a site together.

Tip 4: The open data community

Finally, academics interested in collaboration and open data might like to know about the Open Knowledge Foundation and its work promoting open science:

• The Science Code Manifesto calls for better credit and citation systems for code created during research.
• The Panton Principles are a manifesto for open scientific data.
• The Panton Fellowships support scientists who actively promote open data (this year’s applications now closed).

The Open Science Working Group is the starting point for all the OKFN’s campaigns on open data, open access and open research: join us there.

In the second of our series of guest posts from the SSI Collaboration Workshop, we hear from Mark Woodbridge of Imperial College, who reflects on his own career and his personal experiences of many of the issues raised by the workshop.

_______________

This year will mark my tenth anniversary as a software developer, most of which I have spent in academia. I started out developing a web application in Java using Eclipse on Linux. This much hasn’t changed, despite the rise of Android, NoSQL, HTML5, DVCS and many other technologies and tools. Neither have the basic principles of software architecture, testing, and usability. So I’m lucky that I was encouraged to pick up good habits at the start of my career.

But there have been other invariants. I’m still not sure whether I’m really a post-doc or a member of staff, whether I’m a researcher, an engineer or a programmer, and how my career should develop accordingly. As a computer scientist, I still often feel completely unqualified to communicate effectively with specialists in the department in which I work. And I still do a bad job of explaining my job to friends and family, who assume that all IT people in universities either lecture on programming or fix computers.

Initiatives such as the Software Sustainability Institute and DevCSI (thanks to JISC and the EPSRC) cannot by themselves solve these problems, but they can make a huge difference not only in pursuing their stated goals (such as promoting best practice, building communities around software and promoting the use of local developers) but, as part of this process, providing developers with the tools and resources necessary to advance their own work and careers. This must involve taking the initiative and proving to their institutions that they can cost-effectively develop flexible, high-quality software that exceeds users’ expectations. Having achieved this the results must be shared and promoted to build a positive feedback loop that inspires more faith from universities and funding bodies.

The Collaborations Workshop, which I attended with the generous support of the DevCSI project, is a unique event in providing a discussion forum for all these issues. It’s a developer event that importantly isn’t a hackfest – instead its objective is to encourage collaborative funding applications. However, for me it was about meeting people (invariably experienced, knowledgeable and inspiring) and finding that they struggle with the same things, namely job security, promoting their software, keeping up to date and getting recognition. And I think the best thing we can do, in the spirit of the workshop, is at least try to form longstanding, informal collaborations where we begin to work on solutions to these issues.

For me the foundation of these collaborations are built through discussion (and some serendipity), and the best way to enable this is by getting people together with diverse backgrounds but the same interests, and to let them set the agenda. This was definitely the case in Oxford. The Collaborative Ideas and Break-out sessions were the perfect format: the Five Important Things list generated by the groups should be valuable to anyone working on academic software, and the Lightning Talks slides are a really interesting snapshot of the varied research and backgrounds of the attendees. This is the best reason for attending again next year – the workshop provides an opportunity to learn a huge amount in a very short time about relevant projects, technologies, initiatives, and, most importantly, other developers. This is the knowledge that enables developers to work more productively and justify their role in enabling and supporting research in academia and beyond.

In this guest post, Quanbin Sun from the University of Salford discusses his experience at the Collaborations Workshop 12. Quanbin was one of five developers who received support from DevCSI to attend this event and report back for the community.
_______________

During 21st and 22nd March, the Collaboration Workshop 12 was taking place at Queen’s College of Oxford University. The workshop mainly focused on software development in academic projects and attracted more than fifteen researchers and developers. Thirty two topics were raised and discussed during the two day event and more than twenty lightning talks were presented.
 
 
Among these discussions and topics, I enjoyed the ones that were related to the collaboration between scientific researchers and software developers, and a possible new species for academic research projects – the scientific software developer – who acts between the two or plays a dual role in the research.
 

Who/What is a Scientific Software Developer

 
Alongside the rapid development of computer and computer technology, most recent scientific research will have involved computer software or software development. In the workshop someone mentioned that 40% of research projects were linked to software. We heard about topics such as “Teaching programming to scientist” and “Successful collaboration with computer scientists”, which provided some nice suggestions. However, there are some natural limitations with these approaches. For example, the strength of a scientist relies on their research ability and if they start to care about programming they may lost focus. The computer scientists (referred to as to software developers, for clarification during the discussions) usually care about the quality of the software and cannot be fully aware of the research process.

So we need someone who can act the both roles and carry a software project toward success. Someone who knows the nature of the research and also is familiar with principles of software development.
 

Current status of Scientific Software Developer

 
It is quite common that researchers do programming themselves and as we know this usually result in a poor, non-reusable, non-maintainable software.

EPSRC only invested £9 million per annum in software during the past five years. Compared to the budget of £950M for the year 2012/2013, software seems definitely ignored.

A similar role does exist, but unfortunately there is a lack of identification and the person who does this job has usually not been recognised properly. Such a person may be treated as a RA or RF, although they do a different job. There are some groups (Scientific Software Development and Management, Computational Science, and Computational Scientists and Engineers) on LinkedIn, but we still lack a formal name for whatever we called new species.

Gorissen from University of Southampton mentioned they now have some posts for specialised scientific software developers. There was one workshop participant from Imperial University who has similar job. But the we have not heard much of these from other universities. Henji from Microsoft also mentioned that Microsoft Research (Cambridge) has “Research Software Development Engineers”, although this is not an academic position.
 

Where does a Scientific Software Developer go?

 
The main problem with the role of the scientific software developer is not the lack of a proper name, but the lack of career track and path. There isn’t a senior position for such a role. Eventually, you have to follow the route of Research Assistant –> (Research Fellow) –> Lecturer –> Senior Lecturer –> (Reader) –> Professor if you want to develop your career further. But as a scientific software developer you may lack publications or project grants, which are essential in climbing the academic ladder. If you decided to opt for a career in industry, they may consider you to have no practical experience. So basically, you have wasted your time in such a role, as it cannot provide you with a strong portfolio.

Another problem identified in the workshop is that in bids for academic research projects, the labour of software developer is usually under-estimated, so there may not be enough funding for another developer. From the university’s point of view, having a pure scientific software developer on staff who is not subject to any project is a waste and risk in finance, especially in the current situation of government funding cuts.
 

What is the future of the Scientific Software Developer?

 
Now, and in the near future, scientific software developers will still be a minority in academia. But things are getting better, as Dan Emmerson from EPSRC introduced the Action Plan of “Software as an Infrastructure”. We will expect more funding and job posts in the coming years.