HomeResource hub

Top tips for writing a case for funding a software developer

Bookmark this page Bookmarked

Top tips for writing a case for funding a software developer

Author(s)

Mike Jackson

Estimated read time: 6 min
Sections in this article
Share on blog/article:
Twitter LinkedIn

Top tips for writing a case for funding a software developer

Posted by m.jackson on 24 March 2014 - 10:00am 

v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);}

By Mike Jackson, Software Architect.

You have been developing software that is becoming more popular. But now you are struggling to balance the need to develop and support your software, against the need to do your research. How do you convince funders to give you money to recruit a software developer to keep your users happy?

Here are our top tips in the form of four sets of questions that, by answering, will help you to convince funders.

1. What is the nature, and origins, of your software? What are funders helping to keep alive?

Provide an overview of your software including what it is designed to do, its capabilities and its novel features. Describe your target audience, but also mention other audiences the software might appeal to.

Describe whether it is an application, a library, a middleware or a service and how it is distributed (for example, in source or binary form, its licensing, a free or subscription service, etc.)

Summarise the provenance of your software, how it originated and when; which individuals, projects and organisations have been involved in its development; and who has funded development to date. Include an estimate of the person-hours (funded and unfunded) invested to date in developing the software.

2. Why should funders help keep your software alive? Who will benefit from this beyond just your own research project?

Provide evidence that there is a community that depends upon your software, who need it now and will need it in the future, and explain why they need it. Demonstrate that by funding the development of your software, funders are not just helping you with your research, but are helping other researcher with theirs.

Consider your software in terms of impact. Summarise publications and citation counts associated with your software, both your own and from researchers that have used your software and have publications arising from this. List the domains that your software has been applied in, especially if these are cross-disciplinary or your software has broken into domains that you could not have foreseen. You may also want to visualise the global reach of your software, e.g. the Bioinformatics Support Service at Imperial College London geo-locate downloads of their MRIdb to indicate impact.

Look at the popularity of your software. Summarise the number of downloads, registered users, mailing list sign ups and forum subscribers, Twitter followers, search engine hits for your software and related project resources.

Describe why your software is novel. Summarise your major competitors, both in the academic and commercial sectors, and your unique selling points. These might include correctness, accuracy, efficiency, scalability, customisability, usability, cost, popularity and open source. Highlight any awards, or any other form of recognition, your software has won.

Gather information from your community. Contact your stakeholders, collaborators and existing users for supportive quotes or, ideally, formal letters of support. Set up a community survey to find out who uses your software, what they use it for, any publications they have, how critical your software is to their research, whether they are willing to contribute to the future development of the software, and how they would be willing to contribute. Set up a community survey to find out about potential users of your software, those who are not using it just now but would be interested in doing so, what is preventing them from using your software just now, and what would they like to see from your software. Mention any contacts from other projects or groups about possible collaborations. Demonstrate any commercial interest, as funders can look favourably on such collaborations and the potential for technology transfer.

3. Assuming a software developer is funded, what exactly would they do?

Describe what your software developer would do. Summarise the key features and functionalities they would implement, remembering to relate these to the needs of the users you’ve already listed. These activities can go beyond the software itself to complementary resources such as user guides, tutorials and infrastructure.

Remember that software development goes beyond implementing new functionality but includes improving the software and supporting users in a range of tasks which can include: refactoring your software (to improve usability, maintainability, reliability, efficiency, correctness, robustness, extensibility or inter-operability), bug fixing and testing, writing documentation, managing releases, supporting users, reviewing contributions and managing project infrastructure.

Highlight the role that a software developer can fulfil as a mentor or local expert, providing advice, best practice, guidance, technical review and quality assurance to you, your group or department. This contributes to improving the quality of all the software produced by your group or department, and the software development skills of you and your researchers.

Provide a work plan summarising what your software developer would do for their first 6-12 months, to show to funders that you have a clear picture as to how you will use your developer. Base your initial set of tasks on your requirements and those of your users. Choose as a starting task one that is quite straightforward but would allow your new developer to become familiar with your software and your development infrastructure.

4. If these tasks are so important, what stops you from doing them yourself?

Describe the challenges you currently face in developing the software yourself or within your project. This includes the constraints on your time, what you need to trade-off when developing your software or supporting your users (e.g. does developing new features get squeezed out by teaching? do you sacrifice your research for supporting new users?). Discuss your software’s bus factor and the risks this incurs to both you and your users if unaddressed.

Discuss how these challenges impact not just on you and your project, but on the users who rely upon your software (e.g. in delays to bug fixes or new functionality).

More information

Please see our guide on How to write a case for a funding a software developer. For help in setting up a community survey, please contact us.

Acknowledgements

Thanks to Michael Doube of The Royal Veterinary College, The University of London whose request inspired these top tips, and to Mark Woodbridge of the Bioinformatics Support Service, Imperial College London, who provided valuable feedback and suggestions.

 

 

Share on blog/article:
Twitter LinkedIn