Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,026 | Comments: 44,842

filter by tags archive

Zero Friction and why Defaults Matters

time to read 2 min | 373 words

Several times recently I had to answer why I care so much for defaults if they are something that I can change. My answer is usually a derivative of "defaults matters". I have come to understand that this is not a sufficient answer and I need to clarify it.

I have talked extensively about Zero Friction environment and why I care so much about it. It is about how much I have to fight the tools that I have in order to get what I want.

I spent much of yesterday moving Rhino Tools from MsBuild to NAnt, because MsBuild doesn't have any way to get the current framework version. That is a big task, and considering that I can add this functionality to MsBuild in a few minutes, why did I do that?

Again, it had to do with the fact that when I need a solution, I had to work hard for it. With NAnt, it is just there. For most of everything, in NAnt, it is just there. Between the two, NAnt is the tool with less friction. In the long run, this mean that I would be able to work more efficiently.

How does this related to defaults? Well, consider this, if I have to extend / change something to get something that I consider a baseline functionality, this is a problem. This is friction, and if it generating that much friction early on, I can safely assume that it will generate much more friction when I want to do the advance stuff.

At that point, thanks but no thanks.

To put it in more familiar terms, whatever defaults you have are the Out Of The Box Experience that you have for your software. If you missed the default, it is as if you just hand me a product in one of those ugly and hard plastic shell (the ones that you need scissors just to open) and told me that I can put it in a pretty designer box.

Yes, I can, but you missed your chance to get me.

And that is ignoring the fact that default, for most people, are what is happening. You need good defaults.



What if what you consider to be 'baseline functionality' or a 'good default' isn't what someone else considers them to be?

I'm not suggesting it is totally capricious, but I think a lot of what really amounts to personal preference is often mislabelled 'good'.

Ayende Rahien


I do believe that I am capable of distinguishing between personal preferences and design issues.

Where appropriate, I try to make that clear.

That said, unless there are some really good reasons for those defaults, they get the same treatment. A lot of what I would consider personal preference is part and parcel of the way I am working. And that is damn important.


Of course you are, that isn't in question, but design issues are rarely if ever one-sided, one answer fits all issues, so it isn't an either-or proposition.

This isn't a comment about you in particular, but something I've noticed a lot in the alt.net mailing lists, the lack of understanding here.

It's hard to come up with good defaults in design, especially when design is literally design (by which I mean UI). I think it is also probably true in code.


It's quite possible that NAnt did not come with the possibility to query for the framework (maybe it did, but that's besides the point: I am sure there are other examples). Someone has build it for NAnt, as you had the opportunity to do for MSBuild at this point. You choose not to do so, which is understandable, but someone did do that for NAnt. It seems unfair to judge a young product based on the amount of community contributions.

However, it is fair to chose one product over another because of community contributions. But just be clear about it.

Ted Elliott

MSBuild's building its filesets at startup is what caused me to switch to Nant. Having to go through some awkward syntax to do something as simple as moving some files that you generated during the build into a zip file is ridiculous and just doesn't make any sense. Its easy in Nant.

Ayende Rahien

Oh, yeah. That one was PITA.


hehe, and there you have a good reason indeed. It's ridiculous ;-(

Andrey Shchekin

This is the main problem I have with Castle IoC -- bad support for things I consider to be a baseline.

These are:

  1. An easy way to resolve all dependencies as mocks (and API to do it manually is quite cryptic, though I won over it).

  2. An IEnumerable/List/T[] resolution with logic same as ResolveServices (same API, and also I ended up calling ResolveServices<> from non-generic code -- no fun at all)

  3. An easily discoverable version of BatchRegistrationFacility that can find internal classes (at least that's easy with Linq).

This also demonstrates that such baseline requirements are indeed subjective, since Castle guys haven't implemented them yet (and I consider lists requirement essential).

Ayende Rahien


1/ That is why we have the Auto Mocking Container. An extension to Windsor that does just that.

2/ container.ResolveAll() have both generic and non generic implementations.

3/ That is something that you can write yourself in about half an hour.

Comment preview

Comments have been closed on this topic.


No future posts left, oh my!


  1. Technical observations from my wife (3):
    13 Nov 2015 - Production issues
  2. Production postmortem (13):
    13 Nov 2015 - The case of the “it is slow on that machine (only)”
  3. Speaking (5):
    09 Nov 2015 - Community talk in Kiev, Ukraine–What does it take to be a good developer
  4. Find the bug (5):
    11 Sep 2015 - The concurrent memory buster
  5. Buffer allocation strategies (3):
    09 Sep 2015 - Bad usage patterns
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats