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,844

filter by tags archive

Hibernating Rhinos PracticesDevelopment Workflow

time to read 2 min | 377 words

The development workflow refers to how a developer decides what to do next, how tasks are organized, assigned and worked on.

Typically, we dedicate a lot of the Israeli’s team time to doing ongoing support and maintenance tasks. So a lot of the work are things that show up on the mailing lists. We usually triage them to one of four levels:

  • Interesting stuff that is outside of core competencies, or stuff that is nice to have that we don’t have resources for. We would usually handle that by requesting a pull request, or creating a low priority issue.
  • Feature requests / ideas – usually go to the issuer tracker and wait there until assigned / there is time to do them.
  • Bugs in our products – depending on severity, usually they are fixed on the spot, sometimes they are low priority and get to the issue tracker.
  • Priority Bugs – usually get to the top of the list over anything and everything else.

It is obviously a bit more complex, because if we are working on a particular area already, we usually also take the time to cover the easy-to-do stuff from the issue tracker.

Important things:

  • We generally don’t pay attention to releases, unless we have one pending for a product (for example, upcoming stable release for RavenDB).
  • We don’t usually try to prioritize issues. Most of them are just there, and get picked up by whoever gets them first.

We following slightly different workflows for Uber Prof & RavenDB. With Uber Prof, every single push generate a client visible build, and we have auto update to make sure that most people run on the very latest.

With RavenDB, we have the unstable builds, which is what every single push translates to, and the stable builds, which have a much more involved release process.

We tend to emphasize getting things out the door over the Thirteen Steps to Properly Release Software.

An important rule of thumb, if you are still the office by 7 PM, you have better showed up at 11 or so, just because zombies are cool nowadays doesn’t mean you have to be one. I am personally exempted from the rule, though.

Next, I’ll discuss pairing, testing and decision making.

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



"An important rule of thumb, if you are still the office by 7 PM, you have better showed up at 11, just because zombies are cool nowadays doesn’t mean you have to be one"

This is so true. People think working 12 hour days is good, and bosses love you for it. But all you are doing is introducing bugs due to coding while tired.


So Oren... basically... you are a zombie? How does it work with the others at lunch time :) ?

Ayende Rahien

Njy, For the past week, I have been stopping work at 3 - 4 AM. So yes, I think that I qualify for that statement.


Could you explain what are the " Thirteen Steps to Properly Release Software"? Any links that explain this?


Ayende Rahien

sabanito, I was sarcastically referring to the tendency of some companies to make it really hard to release. Here is an example (doc file): http://www.construx.com/File.ashx?cid=1214


Oh! Ok, but you have some kind of checking routine for the release? Or is it handled 100% by some CI server?

Ayende Rahien

Sabanito, There is release and there there is release. For unstable releases, it is the CI job. For stable releases, we do a LOT of checks.


When I worked there, I don't think I ever showed up as early as 11 :P

Daniel Marbach

Hy oren Why do you consider yourself an exception to this rule? I always wondered what the bus factor of RavenDB is? But certainly if you keep up this pace... your not getting younger :) just thinking out loud!

João P. Bragança

Some people are just built to put the grind on. I shudder to think what his WoW character would look like :)

Ayende Rahien

Daniel, There is also a world of difference between being a founder and being an employee. Also, for me it tends to come in spike, I'll have the muse and work for 18 hours days for a few days, then fall back to six hours day for a week after that. Having the muse is super important for me, and it is worth it.


Just wanted to say that I appreciate the comments about the zombie grind. We need more influential people in the community speaking out against this sort of madness. In my experience, at least, it's still an all too common expectation.

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