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

Hibernating Rhinos PracticesDesign

time to read 2 min | 286 words

One of the things that I routinely get asked is how we design things. And the answer is that we usually do not. Most things does not require complex design. The requirements we set pretty much dictate how things are going to work. Sometimes, users make suggestions that turn into a light bulb moment, and things shift very rapidly.

But sometimes, usually with the big things, we actually do need to do some design upfront. This is usually true in complex / user facing part of our projects. The Map/Reduce system, for example, was mostly re-written  in RavenDB 2.0, and that only happened after multiple design sessions internally, a full stand alone spike implementation and a lot of coffee, curses and sweat.

In many cases, when we can, we will post a suggested design on the mailing list and ask for feedback. Here is an example of such a scenario:

In this case, we didn’t get to this feature in time for the 2.0 release, but we kept thinking and refining the approach for that.

The interesting things that in those cases, we usually “design” things by doing the high level user visible API and then just let it percolate. There are a lot of additional things that we would need to change to make this work (backward compatibility being a major one), so there is a lot of additional work to be done, but that can be done during the work. Right now we can let it sit, get users’ feedback on the proposed design and get the current minor release out of the door.

More posts in "Hibernating Rhinos Practices" series:

  1. (22 Feb 2013) A Sample Project
  2. (06 Feb 2013) Design
  3. (05 Feb 2013) Pairing, testing and decision making
  4. (04 Feb 2013) We are hiring again
  5. (31 Jan 2013) Development Workflow
  6. (30 Jan 2013) Intro


Sean Kearon

How do you document your designs?

Ayende Rahien

Sean, Blog posts :-), emails, those sort of things. We rarely do formal design documents.

Kristof Claes

Do have a post planned on how you introduce new employees to the codebase?


I through that you were going to say "I force them to read this blog" ;)

Chanan Braunstein

Maybe somewhat off topic, but the new TrarnsformResults looks great! I never would have known about because I find it really hard to keep up with the google group and often miss stuff like that. IMO, It would be helpful if you posted threads that discuss upcoming changes, features, suggestions to the blog or ravendb.net - I would love to be able to see and sometimes respond to these exciting new features.

Sean Kearon

Ayende - I like it!

Two quotes that have stuck with me for years are Fowler (in UML Distilled) saying "do enough design" (but no more), and "use the source, Luke" from my Delphi days - they used to ship the VCL source so you could learn from reading it. Wonderful!


When doing specs for user interface features I find that modelling the interaction between the UI and the high level API is the best way to start. This way, if you need to discuss changes on either side, you can easily think about how it effects the other.

Also, impressive use of the word percolate :)

Ayende Rahien

Chanan, What you see there is a design only. It isn't implemented yet. Once we have that implemented, you can be sure I'll be blogging about it and that we will have the docs for it.

Ayende Rahien

Dan, Why impressive percolate ?

Chanan Braunstein

Yes I know. I think it would be useful to have a page somewhere that has a link to all those idea threads so that they can be commented on prior to implementation, just like in that thread you posted from Transform Results.

Ayende Rahien

Chanan, That is why we have the mailing list for. We post several such items a week, this is a big one sure, but we seek feedback on a lot of issues. It isn't practical to post to too many places.

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