Trust

From APIDesign

Current revision

The Chapter 14 contains a note about the importance of trust in the APIDesign. If you broke your promise of BackwardCompatibility once, you repel clients of your API to alternative offerings. It is hard for them to believe that they should once again build their application on top of your API and risk similar problems again.

Reputation

I compared this situation with the importance of trust among banks and today, in the days of worldwide financial problems, I've found confirmation of my parallel:

Trust is a reciprocal relationship, dependent upon a desire to be considered decent and honourable. Even in the dog-eat-dog financial markets, trust and integrity are matters of self-interest. However amoral you may be, it is in your interest to care about your reputation, because if you behave badly you will not do business with me - or others - on favourable terms again. Trust matters. bbq pits smokers

Will Hutton, Guardian

Does that mean we need more BackwardCompatibility in our APIs in order to prevent collapse of software industry comparable to the one on financial markets?

--JaroslavTulach 10:19, 30 September 2008 (UTC)

Keeping a Promise

There seems to be a significant shift in the way people treat their promises these days. In the MiddleAge, when two knights agreed to rendezvous in Paris after spending ten years on battlefields, they had no choice other than to be at the designated place at the designated time. Otherwise, there would be no chance that they would ever see each other again. The MiddleAge promise could last years.

Nowadays, when you want to meet with someone, you simply negotiate the approximate date and an hour of the meeting and phone the other to confirm validity and settle details. Mobile phones are the root cause of modern people being able to break their original promises!

This affects how the whole society behaves and also how (lightly) many developers treat their promise of BackwardCompatibility.

Promises for Days to Come are as Good as None

In the context of the MiddleAge comparison, does it make sense to believe a contemporary developer promising: Our project is in a development stage, but once we reach version 1.0 we'll keep compatibility?

Tracy Chapman explain it all with her song If Not Now... saying that a promise declared “for days to come is as good as none.”

If you are thinking about developing an API in stable way, which you should, commit to it now, during the first release. There is no reason to wait. Otherwise, you are at risk of not keeping your own promises.

What drives me mad is that some people are even proud of doing that! In one useless conversation, while trying to convince people to stick to their previous promise, I heard the claim that, If there is a rule that says I should waste my money on something, then I am personally quite willing to ignore it and even congratulate myself for doing so.

I have the feeling that nothing illustrates the current state of our society better than this quote. People are not willing to keep a promise if it’s even slightly inconvenient.

Where Trust Matters

However, there are still certain areas where promise and trust are more important than profit. I have a few friends working for various banks as stock dealers, where they all work with promises. If they want to make a deal, they call another dealer, negotiate the price over the phone, and as soon as they say “Done,” the deal is made.

Of course, no money is transferred yet. That is the work of the back office and is delayed by a few days. During that time, the deal might fall through and the bank might be tempted to cancel it. However, I have not heard about this ever happening. Even if the bank stands to lose money on the particular transaction, there is always a much higher cost: loss of trust. Because all the operations among the dealers are based on mutual trust, if you break your promise once, rumors spread and nobody is going to do business with you anymore. No bank wants to risk that.

Although I might be wrong, I see APIDesign as another place where trust is more important than cost savings. The contract between the designer of an API and the API’s users is built on mutual trust. Breaking that trust is the last thing you want to do, as that can only help you lose your biggest asset: the users of your API.

That is why it’s more efficient to spend a few bucks more to implement a compatible extension to your API, than to seek the most cost-effective solution at the expense of good relations with your users.

Still, in light of the erosion of promises in our modern society due to mobile phones, it’s safer to eliminate “future” promises, replacing them with real and immediate actions. Those who care can produce good APIs without that exception anyway. If people want to make promises, they should do so immediately.

Promising heaven in the future doesn’t count.