Disposable Software

37 Signals talks a bit about  temporary software.

I really like the idea of shaping your decisions around software based on this simple fact.  I have often thought that Enterprise IT shops could learn a great deal from thinking about software as disposable.  Of course it is, but I am talking about recognizing it and shaping all their practices around achieving a better approach to developing it from that perspective.  Asking themselves "how do we develop better disposable software" and perhaps "how do we make our software more disposable".  I know this seems a bit extreme, but I wonder how it might change things:

• what would it do to the heavy handed development process?
• how about the difficulty in sunsetting software?
• what about the complexity in current solutions?
• how about the huge cost of maintaining those solutions?
• meetings?
• how about the coupling of integrated software?
• standards?
• the speed that solutions get deployed?
• the overall value to the company's bottom line?
• the feedback?

Of course I am not talking about giving up quality or integration, but simply asking whether those would truly be sacrificed by emphasizing the true nature of software. And also what forces would this create as compared to the current ones in place.

Of course this is absurd.  No large IT shop would really change to adapt any such practices that make their software more disposable or even recognize that the company would profit from its disposal.  But, what if one of these shops did?  (I can almost hear Lennon's 'Imagine' playing in the background)

Comments

[Chris Sterling]

I believe that the idea software is temporary is quite relevant in the world of SOA. Jini incorporated this into it's programming paradigm with the Lease. A service or client leases an amount of time with it's software dependencies. We are able to create new services and clients at any point. When the leases are up the services and clients will get the new services to work with.

Even in the XML web services world there is this thought of decommissioning software. IBM has developed the ESA concept and many other vendors have done the same. Back when we were developing COBOL transactions on mainframes there seemed to be this proliferation of print jobs which never ended. I hear there are still print jobs going off in companies which nobody understands the reason for. SOA concepts have taken this into consideration and services at the right granularity can be tracked with metering which could lead to removing the service.

When I am consulting with customers on SOA this is one of the main concepts that I try to put in place. If you are deploying services into your environments which map back to business then you must be able to remove them when that part of your business is no longer relevant. You may even deprecate a version of your service and later remove it when all of the consumers of that service no longer use it. Operational costs in maintaining software is usually the biggest cost of all for large organizations. We must do what we can to make sure these costs are controlled.

[Simon Phipps]

Completely agree here, this is a key consideration that budgeting and employment practice have allowed people to hide for too long. Lately I have been suggesting that TCO ought to include cost-of-exit, and one way to estimate is to evaluate the cost of migration from the chosen software solution to the number 2 solution on the list. I've also been writing on this subject lately - see Freedom To Leave[1].

[1] http://blogs.sun.com/roller/page/webmink?entry=freedom_to_leave

[michael jones]

A nice post! You actually made my interest about software to rise.