Oren Eini

CEO of RavenDB

a NoSQL Open Source Document Database

Get in touch with me:

oren@ravendb.net +972 52-548-6969

Posts: 7,640
|
Comments: 51,260
Privacy Policy · Terms
filter by tags archive

API Design

time to read 2 min | 216 words

There are several important concerns that needs to be taken into account when designing an API. Clarity is an important concern, of course, but the responsibilities of the users and implementers of the API should be given a lot of consideration. Let us take a look at a couple of designs for a simple notification observer. We need to observe a set of actions (with context). I don't want to have force mutable state on the users, so I have started with this approach (using out parameters instead of return values in order to name the parameter):

public interface INotificationObserver
{
    void OnNewSession(out object sessionTag);
    void OnNewStatement(object sessionTag, StatementInformation statementInformation, out object statementTag);
    void OnNewAction(object statementTag, ActionInformation actionInformation);
}

I don't really like this, too much magic objects here, and too much work for the client. We can do it in a slightly different way, however:

public delegate void OnNewAction(ActionInformation actionInformation);

public delegate void OnNewStatement(StatementInformation statementInformation, out OnNewAction onNewAction);

public interface INotificationObserver
{
    void OnNewSession(out OnNewStatement onNewStatement);
}
time to read 3 min | 534 words

Joel Splosky's latest column talks about Sins of Commissions has a lot of good information in it. In particular:

There's a great book on the subject by Harvard Business School professor Robert Austin -- Measuring and Managing Performance in Organizations. The book's central thesis is fairly simple: When you try to measure people's performance, you have to take into account how they are going to react. Inevitably, people will figure out how to get the number you want at the expense of what you are not measuring, including things you can't measure, such as morale and customer goodwill.

Where Joel got it wrong is with the ending:

But we soon realized that commissions weren't the only management tool at our disposal. We simply established as a rule the idea that gaming the incentive plan was wrong and unacceptable. Employees generally follow the rules you give them -- and if they don't, you can discipline them or, in extreme cases, dismiss them. The problem with most incentive systems is not that they are too complicated -- it's that they don't explicitly forbid the kind of shenanigans that will inevitably make them unsuccessful.

And here the train not only goes off the tracks but also start chasing cats.

It doesn't work like that. Oh, I don't doubt that it works this way in Joel's case. The problem is that Joel's point of view is that of a small company, one where he is able to maintain high level of control over what is going on. Let me tell you a different story. When I was in the army, I was part of the military police corps. I spent most of my time in prison, but I was involved in the usual gossips about what is going on in the corp. One part of the corp was maintaining discipline, and the soldiers serving there were rewarded (not explicitly, because that was strictly forbidden) for giving tickets. That was implicit, for doing a good job.

The problem is that there has been many cases in which soldiers has been known to... generate tickets. That is by far no the common case, I have to point out, but it has happened. Now, just to give you a clear idea about what is going on, getting caught doing this was a jail time offense. People still did that.

And sometimes they got away with that for long period of times simply for the fact that the army was so big it took time for this type of things to trickle up.

In any organization of significant size, you are going to have this sort of problems. I have seen salespeople that push a project that they knew wouldn't be profitable, just to pocket their commission. When they were called on the carpet for that, they called that Strategic Loss Leader Projects, and continued doing so. And that was in a place that should have been able to keep track about what is going on. In bigger organizations, the same thing happened, but no one actually caught on to that.

I believe that the term for that is local optimization, to the detriment of the entire organization.

FUTURE POSTS

No future posts left, oh my!

RECENT SERIES

  1. API Design (10):
    29 Jan 2026 - Don't try to guess
  2. Recording (20):
    05 Dec 2025 - Build AI that understands your business
  3. Webinar (8):
    16 Sep 2025 - Building AI Agents in RavenDB
  4. RavenDB 7.1 (7):
    11 Jul 2025 - The Gen AI release
  5. Production postmorterm (2):
    11 Jun 2025 - The rookie server's untimely promotion
View all series

Syndication

Main feed ... ...
Comments feed   ... ...