View Source

This a rough collection of approaches, working practices and mindsets for developers participating in a SPRUCE Mashup. Comments/additions/corrections/links welcome\!

* *Be agile*
** [Develop/prototype in short bursts, then demo and get feedback from your practitioner(s)|http://en.wikipedia.org/wiki/Release_early,_release_often]
** [Practitioner|http://www.openplanetsfoundation.org/blogs/2012-02-21-benefits-collaboration]+[Developer|http://www.openplanetsfoundation.org/blogs/2011-10-11-hackathon-practical-tools-digital-preservation]=Success^2
** If you don’t achieve results within a few hours, you are probably doing it wrong. Try a different approach
** Get crude results quick, perfect and polish later
** Scripting languages can be useful for delivering quick results
* *Re-use, don't re-invent the wheel*
** Most problems have already been solved, although often not by the preservation community
** Someone else in the room (and/or twitter) will have experience of other tools to try, [or check these sources|SPR:Digital Preservation Tools]
** [Experiment with existing solutions first|SPR:Digital Preservation Tools]
** Re-use existing code where possible
* *Keep it small, keep it simple*
** Functional preservation tools should be atomic
** [Modularise in the face of growing requirements|SPR:Tika Batch File Identification]
** Think about how someone else will integrate your tool in a workflow
* *Make it easy to use, build on, re-purpose and ultimately, maintain*
** Share your source
** Automate your build
** [Package for easy install|SP:Debian Packaging]
* *Share outputs, exchange knowledge, learn from each other*
** [Write up your experiences and share them|REQ:Digital Preservation and Data Curation Requirements and Solutions] (sharing less than successful experiences is just as valuable as successful ones\!)
** Publish the data you generate using the [Linked Data Simple Storage Specification|http://www.lds3.org/]
** Shout about it, blog it, tweet it, and [add a tool registry entry|TR:Digital Preservation Tool Registry]

Also see the OPF [PT:Software Development Guidelines].

This manifesto was developed from [wiki|SPR:Tips for determining tool requirements] [posts|SPR:Tips for fast prototyping] by [~techmaurice], along with discussions over the years with other clever people such as [~anjackson], [~carlwilson-bl] and [~davetaz]. Thanks go to them\!

See [this page for more on SPRUCE Mashups|SPR:Just what is a SPRUCE Mashup and what's in it for me?].

*More on smart/agile development*

Also see this external page about [Extreme Programming|http://c2.com/cgi/wiki?ExtremeProgramming].
[Ten simple rules for the open development of scientific software|http://www.software.ac.uk/blog/2013-01-10-ten-simple-rules-open-development-scientific-software]