Software and research: the Institute's Blog

By Steve Crouch.

You've put in the hard work, developed your software masterpiece and it's finally ready. How should you go about releasing it into the wild? In the rush to release your software it's easy to forget a few things. A few very important things! Let's take a look at five things you should consider prior to release...

1. Always release software with a licence

Your hard work in developing your software is just that: it's yours. Without specifying the rights you want to convey to your users, and under what conditions, they could do whatever they want with it - including making a tidy sum by selling it! And without being clear on liability, users could pursue you for damages if something goes wrong when they use it. The onus is on you to protect your interests and the rights to your software.

For an introduction to copyright and licencing, see our guide on adopting an open-source licence.

This week, Newcastle University played host to a Software Carpentry boot camp run by the Digital Institute at Newcastle University, SoundSoftware and The Software Sustainability Institute. This the first boot camp to be delivered entirely by UK tutors, independent of Greg Wilson's team in Canada.

Neil, Steve and Mike joined the Digital Institute's Steve McGough and SoundSoftware's Chris Cannam for the daunting task of running the boot camp, having attended the first UK boot camp at UCL just 2 weeks ago! The attendees' comments were very positive and there was a number of valuable suggestions for future improvements - courses, like software, can benefit from iterative development.

Software Carpentry aims to teach scientists how to quickly build the high-quality software they need, and so maximise the impact of their research. The format is a workshop, or boot camp, followed by 4-8 weeks of self-paced online instruction.

Further boot camps are planned for later in the year at locations across the UK. Keep tuned to our blog or Twitter account and the Software Carpentry website for updates.

By Mike Jackson.

During my work with the MAUS project, Chris Tunnell pointed me at a recent article in IEEE Software by Nicholas Barnes and David Jones on "Clear Climate Code: Rewriting Legacy Science Software for Clarity". The article describes the authors' experiences in completely rewriting an important climate code called GISTEMP.

GISTEMP produces global surface temperature datasets and was subject to criticism, because it was not publicly available and, when it was made available, because it had obvious bugs and could not be run. The authors' decided to completely rewrite GISTEMP to deliver a version that could be accessed, downloaded, inspected and run by any interested party. To this end, they set up the Clear Climate Code project on Google Code to produce and encourage the production of clear climate science software and contribute to increasing public confidence in the results.

The Clear Climate Code paper gives a concise and highly-readable account of the challenges faced by the authors during the refactoring of their code, and describes the research that has been mad possible by the new version of GISTEMP. I'd recommend it to anyone who is interested in scientific software development, or anyone who wants to know why scientific software should be accessible, clear, maintainable and portable (on that note, it is, perhaps unfortunate, that you may not be able to actually read the article unless your institution has access to IEEE papers online, but that's a subject for another blog article).

By Stefan Freitag, European Grid Infrastructure.

At the Mobile World Congress 2012, Andy Rubin (Senior Vice President, Mobile and Digital Content, Google) presented a speech on the rapid growth of the Android operating system. He explained that Google sees 850,000 activations every day, and the total number of activated Android devices exceeds 300 million. This gives you an impression of the extremely large target audience of the Android operating system (OS). As this audience consists of a heterogeneous mass of users, you need to consider a few things before you write an Android app.

By Mike Jackson.

At the "what makes good code good and peer software reviewing" session we ran at Dev8D in February, there was discussion as to the potentially thorny issue of solo developers who may not want others looking at their code. Some people can be sensitive, defensive, or even aggressive at the suggestion that their code should be reviewed or changed, or even fixed!

From a technical perspective, sharing code is a solved problem. A reluctance to share code is a problem of psychology, team working and attitude. After all, programming is a social activity (contrary to the popular myth of the lone developers hunched in a dark room bathed in the light of a cathode-ray tube).

Encouraging developers to share code earlier rather than later, is a challenge not just within research but in software development in general (see, for example, these blog articles on "Don't go dark" and "Programmer insecurity"). In this article, various approaches to encouraging code sharing and communal ownership within a project are discussed.

By Aleksandra Pawlik, Agent and PhD student at the Open University.

1. Think about your audience

Depending on the nature of your software you will need different documentation for different audiences.

The first group, which you always have to address, are your users. Who are they? If you make assumptions about the level of their knowledge, both science- and IT-related, make sure that you list these assumptions in your documentation.

The second group are users-developers, or just developers. The former are scientists who not only use your software, but also develop new modules in order to progress their research. The latter may be software engineers who support a group of scientists that use your software.

The final group are people who maintain and provide IT infrastructure at research institutions. If your software needs to be installed on a server or a cluster, you should provide documentation that enables an administrator to set it up and support its use.

By Mike Jackson, the Software Sustainability Institute.

On Monday and Tuesday this week, members of the Software Sustainability Institute joined over 40 scientists for a Software Carpentry boot camp at University College London. Software Carpentry aims to teach scientists how to quickly build the high-quality software they need, and so maximise the impact of their research. The format is a workshop, or boot camp, followed by 4-8 weeks of self-paced online instruction.

By Quanbin Sun, Research Student at the University of Salford.

On 21-22 March, the Collaboration Workshop 2012 took place at The Queen’s College, University of Oxford. The workshop mainly focused on software development in academic projects and attracted sixty 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 plays a dual role in the research.

You're about to embark on the development of a new piece of software. Of course, there's a whole host of things you should do. But let's look at the flip side of the coin: what shouldn't you do?

1. Don't develop code that you can't maintain

It's all too easy to fall into bad habits, especially if you're up against a tight deadline. In the long run, good coding practices will save you a great deal of time and stress. It will also make growing the software a far more enjoyable process. After all, who likes fighting their way through an unclear spaghetti of code just to make a basic modification?

At the start of a project it's not always clear who else will become involved in developing the software. If other developers join your project, they will need to understand the code before they can develop it themselves. Good code can avoid a lot of problems (and embarassment when you show other developers!).

Writing readable, commented, easily understood and well-structured code doesn't take as much effort as you'd think, and it's even easier with the Institute's handy guide on developing maintainable software. You should also code defensibly - avoiding unnecessary and complex dependencies and deprecated interfaces - which is covered in our defending your code guide.

By Ilian Todorov, Advanced Research Computing Group, STFC.

This article represents my personal point of view. It is related to Dirk Gorissen’s blog post “The researcher programmer, a new species?” and discussions from the “Scientific Software Development and Management” group page of LinkedIn, which started after the Software Sustainability Institute’s Collaborations Workshop 2012 (CW12). These discussions pertain to why the software engineer in academia needs recognition.

Software has become a technique of choice for many scientists. It is often considered to be free, but this often means “free to academia”. Somewhere down the line, someone has paid for it. Someone has invested their labour in writing code instructions to implement a scientific methodology of some kind. In most cases, this was a postgraduate (PG) student and/or post-doctoral (PD) researcher attempting to automate and simplify the workflow of their research routines.

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 their research performance, as measured by the impact of their research papers in peer-reviewed journals. More papers in high impact journals leads to more success and recognition, and better chances when applying for funding or academic jobs. In contrast, software development has diversified. It has become a well-defined profession with many sub-fields and computer languages. This is not surprising for an industry that governs our lives at home – PCs, games, smart devices, apps – at work and anywhere we go – databases, financial transactions, GPS, industry. It has also become a discipline in its own right in higher education as “informatics” or “computer science”.