Just the thought of the effort and cost required to implement software preservation measures can seem high when compared to the potential benefit. The costs are self-evident, whereas the benefits are not. One way of dealing with this impasse is to not to splurge now, but to invest a little to give you the option of doing something more in the future. In essence, get value from flexibility.
How does this work in practice? Take for instance the end of a project where you’ve built and used some fragile and not-particularly-well-documented software. It did the immediate job, but isn’t ready for anything else. The follow-on project that should build on the software doesn’t start until next year, or is contingent on getting more grant funding. The traditional options might be to either do nothing with the software and go straight into the next activity (i.e. abandon ship and let the software and tacit knowledge fester), or to spend a couple of weeks fully documenting the software and making it robust.
Instead, do the minimum necessary for high-level documentation and basic test data. Commit to reviewing the software’s prospects in a year or so. If there has been subsequent interest (internal or external) in the software that could lead to sizeable benefits (institutional reuse, kudos through external use, etc.) then whatever additional effort is required to achieve those benefits can be considered. If not, then little has been lost. Without the upfront effort, you either have an uphill struggle to go from scratch (= big lose!) or you’d have saved a small amount of effort (= small win).
Giving yourself some flexibility – by leaving code in a recoverable state rather than abandoning it – could well be an effective strategy for many. It has minimal upfront costs but retains the potential benefits. The value of such flexibility can be sizeable: a stitch in time saves nine.