You've finished your analysis and now you would like to present it to the world, preferably on a pretty but informative picture. But where do you start and what software should you use? Here are some top tips to help you out.

Once your software development goes beyond simple hacking, your productivity will be improved by using a version control system (VCS). A VCS allows you to keep track of all the changes to your software during its development. It enables you to roll back the clock to see how something worked at any point in the software’s history. Simply put, I could not work without the peace of mind that the version control system gives me. And if you ever want to involve others in the development of your software (and you probably will), version control becomes all but essential.

There are many different approaches to sustainability. The way that you approach sustainability will depend on many factors, such as how important is the software, how mature is it, what is the size of its community and what resources available for achieving sustainability? Here is our breakdown of the different approaches to achieving software sustainability.

Technical preservation (techno-centric)

Software is reliant on hardware, and hardware changes when each new model is released. Over time, hardware will change to such an extent that older software will not run on the latest hardware. Without the hardware to run on, software becomes redundant.

The easiest way to ensure that there will always be hardware on which to run your software, is to preserve the hardware (and its operating system and any other reliant software). Technical preservation has one big benefit: it’s easy. You simply continue business as usual. There are drawbacks to this approach. The first is maintenance. Over time, hardware components will wear out and must be replaced. If the hardware is no longer manufactured, components become scare and expensive. Ultimately, you may find yourself with broken hardware and no way of fixing it – leaving you with redundant software. The second drawback is isolation. If your software only works with very specific hardware, you limit your users to those people with the right hardware. This could be a very small group.

Technical preservation is a straightforward approach to sustainability, but it’s only reliable whilst you have a stockpile of spare parts.

Emulation (data-centric)

You want to keep your software, but you’re worried that technical preservation might leave you with no hardware or an expensive maintenance bill. The alternative may be emulation. An emulator is a software package that mimics your old hardware (and, possibly, your operating environment) so that it can be run on any computer.

Emulation gives you the flexibility to run your software on new hardware, which gives your software a new lease of life. As always, there are drawbacks. You need to find an emulator. You might be lucky and find one available under a free-to-use licence, or you might be able to buy one. However, if your old hardware was rare, you may find that no emulator exists. In this case, you either have to write an emulator yourself, which requires specialist skills and could be expensive, or explore another of the sustainability approaches. It is difficult to write an emulator that perfectly mimics the old hardware. This can lead to differences between the operation of the old hardware and the new emulator, which could manifest themselves in annoying quirks or more serious problems.

Emulation allows you to keep your old software, but requires the existence (or in-house development) of a reliable emulator. It also adds a dependence on the emulation software, which - like any other software - could itself become obsolete.

Migration (functionality-centric)

If you need to reliably reproduce the operation of your software, the best choice may be migration. With this approach, you re-code your software so that it will work on new hardware or operate with new and reliable software. Re-coding for migration also gives you the perfect opportunity to enhance your software’s operation by fixing bugs or adding new features.

There are many migration approaches. They range from a complete re-write of the code, which allows your software to be used on a completely different system, to continual migration, which keeps your code up to date with the latest (generally small and continual) changes to the hardware and software that your code relies on.

A complete migration to a new system is the same as writing new software – possibly harder because you are constrained by the old architecture. This leads to migration’s biggest drawback: it’s resource heavy. It depends on the complexity of your old software, but migration might need the investment of a significant amount of time.

At some point in its lifetime, most code will be subject to a change in the hardware and software that it relies on. For example, your code might need to be tweaked to use a new version of Java or the latest version of an operating system. This is partial migration.

Migrating your software completely produces a new software package that reliably reproduces the operation of the old software, but it could require a significant investment of resources. Continuous migration is a less arduous task than complete migration, and is generally necessary if your code is to stay in use over a long period of time.

Cultivation (process-centric)

Sustainability requires the investment of resources. Cultivation is one of the best ways of sharing the responsibility for these resources. Cultivation is the process of opening development of your software. This is where you allow developers access to your code – under a licence – so that they can work with you. The deal is that outside developers get access to your code so that they can adapt your software to meet their exact needs, but any bugs they fix or new functionality they add is given back to your project.

Cultivation allows more contributors to be brought into your project, which helps share the sustainability workload. Apart from having more people to work on the code, a larger group of developers means that knowledge about your software is more widely distributed. This means that the departure of one developer is less likely to have a catastrophic affect on your software’s future.

Cultivation’s main drawback is that it’s a long-term process. Cultivation is not suitable as a quick fix to ensure sustainability in the short term; it requires effort and planning over many months and years. Cultivating an open-development community is not as simple as making your source code publicly available. You also need to invest time into building your community, which requires work to understand what your community wants and how to appeal to them. The goal is to build a community that is self-sustaining so that the future of your software is assured.

Cultivation promises a self-sustaining community of developers who work together to keep your software up to date, but requires work to cultivate the right community for your software.

Hibernation (knowledge-centric)

Rather than sustaining your software in an operational state, you could choose to hibernate it. Hibernation could be the right approach to follow when your software has come to the end of its useful life, but there is the possibility that the software might need to be resurrected to double-check analysis or prove a result. Alternatively, there may not be a user community for your software, but you believe one will occur in the future. Hibernation allows you to preserve the knowledge about your software so that it can be easily resurrected in the future.

Hibernation can be a one-off process. Unlike sustainability, which requires a continuous investment of resources, the hibernation process can have a beginning and – importantly – an end. Preparing software for hibernation can be resource heavy, and if the software is never resurrected you may feel that those resources were wasted.

Hibernation allows you to store software that you do not currently need, but it requires a significant – if short lived – investment of resources.

Deprecation

If software lacks a community, the resources to continue or a developer, then the only alternative might be deprecation. All effort invested into the software comes to an end, but, unlike hibernation, no effort is invested in preparing the software beforehand. In the future, if someone wants to use the software, they may not be able to find a stored copy and it might be expensive or impossible to resurrect the software.

Deprecation is easy to perform, but often marks the end of a software package’s life and is typically only chosen when no other option is available.

Procrastination

“Never put off until tomorrow that which can be done the day after tomorrow... or the next day”.

Procrastination is certainly the easiest of all the sustainability approaches, but things rarely turn out for the best when left to their own devices – and that applies to software too.

You have the opportunity to embark on an exciting new collaboration with another project. You can see it has great potential to deliver something great - the sky's the limit! But what should you do, and look for in your collaborators, to ensure you establish a solid foundation for the relationship before you pour effort into a workplan?

If you want people to use your research software, it needs good documentation. Many people employ the help of a technical writer to write documentation, but how do you get the best out of this relationship? We turned to Craig Haiss for help. He set up HelpScribe to share his ideas with the technical writing community, and in 2010 it was named one of the most influential technical writing blogs on the web.

Deciding upon a computing infrastructure for your project can be a daunting task. Do you want to use your institution’s existing infrastructure, buy a new one, or go for a third-party? Would an in-house cluster be best or a commercial cloud platform? Regardless of whether you seek a cluster, grid, cloud, HPC facility or volunteer computing infrastructure, there are a number of things you should consider.

The first encounter a user often has with your software is when they download it as a package. The nature of this package, and what the users have to do with it, can make the difference between a happy user using your software for their work, and a frustrated user, who has wasted a morning, and is now looking elsewhere.

You might be interested in a Software Carpentry boot camp for your institution or research group. Although we think that a running a boot camp is one of the best ways to learn about software development, we realise that some people can't set aside the time, effort, or expense to organise one. Here are some alternatives you might want to consider.

Having been an instructor on four Software Carpentry workshops, and inspired by Aleksandra Pawlik's top tips for helpers at a Software Carpentry workshop and Phil Fowler's on hosting a workshop, here are my top tips on being an instructor.

By Steve Crouch, SSI Research Software Group lead.

This guide is the second in the Unit Testing for Scale and Profit series.

In our last episode we looked at the benefits of unit testing, and how it can help us automate the verification of correct behaviour with our software. After designing and writing a number of tests using the pytest testing framework, we were able to run them and see whether those tests were successful, and using a tool to measure unit test code coverage we were able to see to what extent they tested our code as a whole. But as our code increases in size and particularly complexity, we should expect our number of tests to increase too, which means more time writing tests. Fortunately there is something that can help with this burden which we'll look at in this episode: parameterised tests!jacek-dylag-nhCPOp4A2Xo-unsplash.jpg