The SPRUCE Mashup Manifesto

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)
  • Practitioner+Developer=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
  • Experiment with existing solutions first
  • 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
  • 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
• Share outputs, exchange knowledge, learn from each other
  • Write up your experiences and share them (sharing less than successful experiences is just as valuable as successful ones!)
  • Publish the data you generate using the Linked Data Simple Storage Specification
  • Shout about it, blog it, tweet it, and add a tool registry entry

Also see the OPF Software Development Guidelines.

This manifesto was developed from wiki posts by Maurice de Rooij, along with discussions over the years with other clever people such as Andrew Jackson, Carl Wilson and David Tarrant. Thanks go to them!

See this page for more on SPRUCE Mashups.

More on smart/agile development

Also see this external page about Extreme Programming.
Ten simple rules for the open development of scientific software