Just about everyone has become attuned over the last few years to the concept of sustainability. Except, it seems, when it comes to software practices. In most IT environments, by far the largest chunk of costs associated with a given piece of software, surface after it is initially delivered. That is true of purchased packages, as well as for custom code. And yet most organizations don’t properly budget for the total lifecycle costs for a piece of software. More importantly, neither do they plan and build software for sustainability. And very few actually plan and budget for the costs of decommissioning a system that is no longer sustainable (either technically or economically) or is no longer needed – until that decommissioning is long overdue!

“We Support the Future!”

This is not a new problem. Many years ago I was involved with an organization known as the Software Maintenance Association (SMA). Prior to the so-called Y2k thing a decade ago, the SMA struggled to garner the respect it deserved. As Y2k loomed, the SMA became a valuable focal point for software remediation practices and tools. Post Y2k, I have not kept up with the fortunes of the SMA, but I will always remember their slogan – “We Support the Future!” That always struck me as a fresh and compelling way to think about the disciplines and activities associated with keeping software doing what it needs to do. It also reminds me that much of today’s software practices are focused on the here and now, with relatively little regard for future sustainability.

How to Make Software Sustainable?

Given the complexity behind the issue and in an attempt to increase the value of this blog to its readers, I’m going to approach the topic of software sustainability as an experiment in collaboration. I will create a series of posts over the next month or so, incorporating as much dialog and discussion as I can surface. I welcome, as ever, any and all commentary on this blog. But I will also leverage other means (e.g., social media, personal network) to discover the state of the art and surface leading or promising practices.

I am hopeful that we can generate useful commentary, experiences and shed some helpful light on the topic. As a starting point, I propose three major categories or ‘lenses’ through which to explore sustainable software practices:

Technical

People

Financial

To help get things kicked off, here’s my initial thinking on these issues.

Sustainable Technical Practices

There is no doubt in my mind that Enterprise Architecture is key here. My colleague and friend Roy Youngman describes this appropriately as “a means to reduce the cost of change.”

There’s been some very good news here over the last few years. Standards have emerged that while not being panaceas, can help in bringing a more ‘architected’ approach to software – more ‘plug and play’ as it were. Service Oriented Architecture (SOA) and derivatives such as Web Oriented Architecture (WOA) have shown significant benefits. Unfortunately, much of the evidence is anecdotal due to a lack of good software management practices – in particular, good metrics, uniform terminology, enlightened costing models (e.g., activity based costing) and good baseline data.

Ironically, the lack of good data exacerbates the challenge of building a business case sufficiently robust to drive real change in software practices. As such, in spite of their promise, these standards are still not commonplace, their adoption impeded by forces such as organizational inertia, lack of an architecture infrastructure with sufficient ‘teeth’ to shape behaviors, and by all the packaged software that organizations increasingly rely on. These bring their own architectural idiosyncrasies (or lack of architecture!), leading many organizations to have effectively outsourced their architecture – often unwittingly, and almost always, unwisely!

There is other good news in contemporary development methods such as Agile and its Scrum derivative. Being based on iterative refinement, these inherently create and, to a degree, enforce sustainability into their products – each iteration must, in some respects, ‘anticipate the next iteration.’ Furthermore, Scrum roles such as Product Owner, if well implemented and connected with broader Product Management roles (responsible for total lifecycle costs and value) can bring a great deal to sustainability.

Sustainable People Practices

The challenge here, especially with agile development models, is that the teams run at a relentless pace. The question is, can people sustain this pace day in, day out? Does Scrum become a euphemism for ‘heroic efforts’ that leave people sick or with broken families?

I believe the last couple of recessionary years have left IT staff’s depleted, less than fully engaged and with deteriorated organizational talent management practices. While the pace of technological change continues to increase, most organizations have actually decreased their investment in training and competency development over the last couple of years.

Sustainable Funding

I’ve joked before that a consultant can often score a cheap point by telling a CIO, “Your IT funding model is broken!” It always is! Funding models typically evolve over many years, without sufficient consideration as to the desired behaviors they should lead towards. On top of this built-in dysfunctionality, IT project teams, by way of either reducing “sticker shock” or simply because they’ve not done the analysis, don’t plan and manage in terms of full lifecycle costs.

Let the Sustainable Software Discussion Begin!

So, with those few initial thoughts:

How do you see the issues of sustainable software at your organization?

What priority does software sustainability have in your organization today?

2 thoughts on “The Challenge of Sustainable Software”

Great article, thanks for posting. However, I’m not sure your understanding of Scrum is correct. Teams are not required to work heroically. In fact, teams determine how much they accept. Furthermore, all tasks should be no longer than a single work day. Scrum is 100% sustainable. The real issue here is that all projects should have a start and finish. Never-ending iterations are susceptible to gold-plating, low-value features, and burnout.

I appreciate the comment and clarification. I understand that Scrum does not require “heroic efforts.” However, I have seen IT environments where developers to experience new types of stress as a by-product of “high intensity” development approaches. I do see this as a danger – at least as these methods are implemented by some organizations.