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


Eric Hauser

You should definately get the latest. Starting with the one they labeled release candidate I have noticed a significant speed increase over the other nightly drops.

Petar Repac

My team is looking for ways of increasing productivity.

Could you or others give some estimation of productivity gain when using Resharper compared to using plain VS2008 ?

Thanks in advance.


Ayende Rahien

351.54% productivity increase.

Ilya Ryzhenkov

They counted it here: http://blog.noop.se/2008/05/22/ReSharper+40+Beta+Is+Out.aspx

So for that case, the number is something like 326%

However, if we add live templates, create from usage, extract method refactoring, the number could be something like 400% or more.

Petar Repac

351.54% productivity increase.

So you went to sleep and in the morning R# finished the project ?


Petar Repac

Joking aside, how did you get the 351.54 % ?


I guess Oren calculated from the number of characters you need to type.

Alex Simkin

VB.NET 9.0 programmers can ignore this announcement.

Petar Repac


My guess would be that R# keeps this statistic and shows it on demand.


Or he could have pulled an absurdly precise number out of thin air as a zen way of highlighting out the impossibility of deriving such a distilled quantification that has any meaning.


I don't believe in such precise numbers. I hope this is not more than funny - to put such qualified numbers.

BTW, how do you think how much MS can pay and will to Re# team to incorporate their work into VS.vNEXT? =)

Petar Repac


Yes, I also was under impression that Oren was a little sarcastic.

Anyway I wasn't looking for some precise number, but for general feedback in productivity gain from developers that use R#.

Regards, Petar


where is the jetbrains ide

Marcin Seredynski

Petar, remember that 83.27% of the statistics are made up on the spot ;). Although R# is a great tool and saves a lot of typing, majority of the work happens inside the developer's head. Productivity boost comes from a responsive environment that does not get into your way - R# is pretty good at making a good code editor out of VS2008. Ideally, I would like to have R# for Notepad++, to get faster load times :)

Lucas Goodwin

I've seen atleast 3 times the increase in productivity in terms of refactoring operations. Move and Rename are unbelievably time saving.

The other gains I've experienced have been more due to how well R# supports the TDD process via it's tooling. Auto-creation of methods, classes, etc. Saves a good deal of time and allows me to focus more on the design aspect of TDD.


Alex: don't they have a separate VB edition?

By the way, has anybody worked with DevExpress' CodeRush? How does it compare to R#?

Petar Repac


As I understand it CodeRush is code generation tool so it shouldn't be compared with Resharper.

DevExpress has Refactor! Pro and it is more suited to be compared with Resharper.

Mats Helander


I find that the productivity raiser in tools like resharper has a lot to do with how they help you deal with mistakes (think: rename). This means that a coder who makes a lot of mistakes may see a greater productivity increase.

In other words, your devs may not become that much more productive with Re#. If you hired me, otoh, you could probably see something like a 5000% productivity improvement. Of course, I would charge a premium rate for such amazing productivity increasing potential! ;-)



So, anybody tried Refactor! Pro? Their list of refactorings looks pretty impressive..

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