JaroslavTulach: /* Where Trust Matters */ - 2018-11-05 10:46:01

Where Trust Matters

←Older revision Revision as of 10:46, 5 November 2018
Line 41: Line 41:
few friends working for various banks as stock dealers, where they all work with promises. If they want to
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,”
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
+
the deal is made.
-
a few days. During that time, the deal might fall through and the bank might be tempted to cancel it. How-
+
 
-
ever, I have not heard about this ever happening. Even if the bank stands to lose money on the particular
+
Of course, no money is transferred yet. That is the work of the back office and is delayed by
-
transaction, there is always a much higher cost: loss of trust. Because all the operations among the dealers
+
a few days. During that time, the deal might fall through and the bank might be tempted to cancel it. However,
-
are based on mutual trust, if you break your promise once, rumors spread and nobody is going to do busi-
+
I have not heard about this ever happening. Even if the bank stands to lose money on the particular
-
ness with you anymore. No bank wants to risk that.
+
transaction, there is always a much higher cost: loss of [[trust]]. Because all the operations among the dealers
-
Although I might be wrong, I see API design as another place where trust is more important than cost
+
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.
-
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
+
Although I might be wrong, I see [[APIDesign]] as another place where [[trust]] is more important than cost
-
API, than to seek the most cost-effective solution at the expense of good relations with your users.
+
savings. The contract between the designer of an [[API]] and the [[API]]’s users is built on mutual [[trust]]. Breaking
-
Still, in light of the erosion of promises in our modern society due to mobile phones, it’s safer to elimi-
+
that [[trust]] is the last thing you want to do, as that can only help you lose your biggest asset: the users of your
-
nate “future” promises, replacing them with real and immediate actions. That is why I am trying to remove
+
API.
-
the exception for the temporary status of the NetBeans official APIs that allows them to stay unstable for one
+
 
-
release. Those who care can produce good APIs without that exception anyway. If people want to make
+
That is why it’s more efficient to spend a few bucks more to implement a compatible extension to your
-
promises, they should do so immediately. Promising something for the future doesn’t work.
+
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.

JaroslavTulach at 10:41, 5 November 2018 - 2018-11-05 10:41:47

←Older revision Revision as of 10:41, 5 November 2018
Line 1: Line 1:
-
The [[Chapter 14]] also contains a note about the importance of trust in the API design. 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.
+
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:
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:
Line 11: Line 13:
--[[User:JaroslavTulach|JaroslavTulach]] 10:19, 30 September 2008 (UTC)
--[[User:JaroslavTulach|JaroslavTulach]] 10:19, 30 September 2008 (UTC)
 +
 +
=== Keeping a Promise ===
 +
 +
{{:MiddleAge}}
 +
 +
 +
=== 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''?
 +
 +
[[wikipedia:Tracy Chapman|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. How-
 +
ever, 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 busi-
 +
ness with you anymore. No bank wants to risk that.
 +
Although I might be wrong, I see API design 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 elimi-
 +
nate “future” promises, replacing them with real and immediate actions. That is why I am trying to remove
 +
the exception for the temporary status of the NetBeans official APIs that allows them to stay unstable for one
 +
release. Those who care can produce good APIs without that exception anyway. If people want to make
 +
promises, they should do so immediately. Promising something for the future doesn’t work.

JaroslavTulach: New page: The Chapter 14 also contains a note about the importance of trust in the API design. If you broke your promise of BackwardCompatibility once, you repel clients of your API to alter... - 2018-11-05 10:26:51

New page: The Chapter 14 also contains a note about the importance of trust in the API design. If you broke your promise of BackwardCompatibility once, you repel clients of your API to alter...

New page

The [[Chapter 14]] also contains a note about the importance of trust in the API design. 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.

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.''
[http://bigbubbas.wordpress.com bbq pits smokers]

Will Hutton, [http://www.guardian.co.uk/commentisfree/2008/sep/28/globaleconomy.creditcrunch 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?

--[[User:JaroslavTulach|JaroslavTulach]] 10:19, 30 September 2008 (UTC)