'Trunkless' development

Following on from our last post, about developing simple software, we'd like to describe how we used this in practice, taking the Engineering Department's TODB software, making custom versions for six other departments, and making them feel able to take responsibility for maintaining and supporting it into the future.
We plan to publish this also as part of a companion whitepaper to the e-Admin project final report.
Overview
A method of spreading user-originated software in HEIs, which allows each user a ‘made to measure’ customised version of the software, for which they are subsequently able to take complete responsibility.
Model summary

1. Prototype developed by originating user
2. Other users interested
3. Central, one-off funding obtained for development
4. Software is genericised, with a view to making expected range of stakeholder-specific customisations manageable
5. Software deployed and customised user by user. Users and developers agree priorities for development.
6. Lessons are incorporated back in to generic version and pushed to previously-addressed departments
7. Detailed, tested documentation and handover to users

Prerequisites

• A working prototype exists
• At least some partner institutions have expressed an interest in evaluation with a view to adoption
• Institutional IT systems are unlikely or unable to assume similar functions in the project timeframe

Suitable projects

• Small to medium-sized applications in which the use of frameworks, large or numerous libraries, or substantial amounts of abstraction is unnecessary. It is worth noting that lots of ‘big’ projects are actually small, once all the abstraction and configuration capability needed to handle different user requirements is stripped out.
• Projects with a user base of approximately 3-20 users, each with distinct needs. If the numbers are larger or the requirements uniform then a traditional open-source approach is likely more efficient.
• The risk of having to apply similar and significant changes to all systems subsequent to deployment is small.
• It is not critical that all systems interoperate consistently. If it is, then centralised systems are likely to be more effective, as the overhead of 'softly' maintaining interfaces will offset the advantages of locally-maintained, locally-modified software.
• Administrative tools are in general likely candidates.

Model benefits

• Software which, being created by academics, addresses their particular needs very well, can be genericised and then customised repeatedly for other users. Traditional, centrally budgeted and supported systems would not be able to provide such customisation at a reasonable cost owing to ongoing support requirements, and in any case are unlikely to invest a great deal of effort on behalf of relatively limited numbers of users, unless there are substantial financial or educational benefits.

Model limitations

• Originators are by definition able to resource a modest level of formal or informal development, and are likely to be able to do so again, if necessary. However, without the benefit of JISC or other capital funding it is not possible to re-engineer and distribute systems in this way.
• Less well-resourced adopters will be able to maintain the software, but not to extend or make significant modifications.
• The model is good as long as it is not subsequently necessary to apply similar but significant changes to all the deployed, customised systems, in which case support cost has been multiplied.
• The model accommodates large variations between sets of users, and becomes leaner, more efficient, and more like a conventional ‘one size fits all’ development approach as this variability decreases. It might become apparent that actually a one size fits all approach would have been appropriate, in which case architectural inefficiency might result from having followed the TODB approach initially.
• This kind of project might benefit from having fewer staff, for a longer period; or from being able to draw on a developer ‘pool’. This would overcome difficulties in hiring great staff for a short term. Longer, lower intensity projects also allow more time to talk and work with other institutions, once the local systems and processes were established.

Caveats
Because our partner departments are only now, at the end of the project, falling back on their own capabilities for maintenance and support, and because none save Engineering have as yet used the software over a complete academic year, we can not say that evaluation is finished. It needs a long view over coming years, which CARET will be providing.