Possible missing play: Plan for Sustainability

[ncoghlan]

There's a saying that "writing software is cheap, maintaining it is expensive". When writing digital services, it's tempting to believe that there will come a time when they're "done". In practice, that isn't the case, as these services exist in an ever evolving environment:

• technologies to create, maintain and access digital services change
• user, developer and administrator expectations change
• regulations and other requirements change

Sometimes it's even necessary to swap out the entire technology stack of a digital service, without breaking other applications written to use that service.

Small startups and relatively new companies don't need to worry about these things, as it doesn't make much sense to expend energy on issues that are likely years away from causing problems, when your main concern is whether or not you'll be able to pay the bills next month. Writing "institutional software" that may end up being in service for decades is a different story - it's necessary to recognise up front that the "care and feeding" of these services is something that will require ongoing investment for as long as the service is in operation.

Many of the other plays (especially the use of agile iterative practices and the use of automated testing) are specifically aimed at implementing a sustainable approach, but step one is really to acknowledge the need for long term sustainability in an institutional context.

[camerons]

Extending on ncoghlan's suggestion, sustainable development requires consideration of:

• The full software lifecycle, from concept, to development, to maintenance, to retirement. What is the exit strategy? This question is usually easy to answer when using open standards and open source, hard to answer when caught in a vendor lock-in proprietary solution.
• Modular design architectures, also called "open architectures". With modular architectures it possible to update one component without impacting an entire system.