Why transactions are often under used

Back here I mentioned that on many occasions I've come across companies and products that could/should be using transactions when they're not. Obviously the inverse is also the case: the use of transactions when they're simply not needed can leave people with a bad experience and hence averse to looking to transactions in the future, when perhaps they should. So, the reasons for people not using or considering transactions when they are in fact useful can be broken down into two broad categories:

(i) overhead: it's true that you can never get something for nothing. But as we showed here with regard to principles, and I mentioned here with regard to our specific implementation, it doesn't have to be the case that you have to pay dearly (in terms of overhead and cash) to get the guarantees transactions offer. There's always a trade-off to be considered in pretty much any additional functionality you may want to add to an application, whether it's transactions for reliability/consistency, replication for availability/performance, security etc. Rather than think about what negative impact this functionality is going to have on your system, you need to consider what the impact will be on not having it. Now with the likes of security and replication it's fairly evident what benefits they bring most of the time. With transactions it's always a little more difficult, because most of the time you don't see the benefit: it's typically only when a failure happens. Now it is true that failures are not common, but they do happen - network failures, disk failures, memory failures etc. But in that case you should think of transactions like an insurance policy: how often do you claim on your home, car or travel insurance? Probably not that often. But most people will still renew their policies year after year, even when some (e.g., holiday insurance) aren't mandatory. Why? Because you don't want to take the risk and in simple terms the cost of insurance is significantly less than the cost of whatever it is that you're insuring. I'd like to see a time when transactions are seen to be so cheap that they're just part of the infrastructure that people take for granted. I think with something like ArjunaCore and the transaction implementation in Indigo that's starting to look possible.

(ii) education: in some ways this follows on from the above discussion, where people (architects, engineers etc.) either have a bad previous experience of transactions or have heard rumours. However, there are at least a couple of other sides to this: first, people (biz-dev as well as engineers) simply not knowing that transactions exist (computer science is a large field, so it's not always the case that everyone knows about every one of its facets). More worrying though is the second aspect, which I've seen a few times - vendors of products that really could (and should) benefit from transactions not using them because they either don't understand the reasons why they need them (education again) or they don't want the perceived overhead in their products and are willing to take the risk (on behalf of all of their customers) that failures won't ever happen; and they may do it "silently". It's this last point that always annoys me and not simply because I've been working with transactions for a long time: if you go back to the insurance analogy, it's the equivalent of you buying insurance but the insurance company simply pockets the money and if/when you come to make a claim they feign ignorance, leaving you up the proverbial creek without a paddle. By the time you know there's a problem, it's already too late!

I think that there's a lot that we as a transaction industry can do to help this, through education, evangelising and improved product functionality/performance. But I also think there's a lot that the user can do, for instance by considering what the effects of failures might be in certain scenarios and, particularly in the case of 3rd party products/components where you might have been told failures "are handled", drill down into the "hows" and "whys" rather than just taking it for granted. You don't buy insurance from just anyone; you use trusted parties, such as banks, where trust is built up and the products assured and backed by the law. It's a shame we don't have something equivalent for software.