Please, STOP adding new features

ReSharper is a great product overall, but there are quite a few annoying bugs to put up with. Please seriously consider spending A LOT of time on a release that ONLY fixes bugs - no new features. Sure, it would be an unconventional approach and your marketing department will hate you, since you can't exactly put "has less bugs" as a bullet point on the brochure, but I think your customers (developers) will appreciate it.

It has enough features already. Quite honestly, I hardly ever find myself thinking "I wish ReSharper did X" (some fancy new refactoring or whatever). On the other hand, I find myself thinking all the time "argh, I WISH ReSharper didn't leak memory so badly, I wish those damn tool windows would stay where I put them, I wish it Unit Test Runner would build the solution when needed and not build it when not needed, I wish I could switch between Debug and Release configurations, I wish IntelliSense would work first time when I type 'override'", etc., etc.

I think it's worth noting that the JetBrains support staff are great and genuinely do their best to help with problem. At the end of the day, however, there's only so much they can do to keep a customer happy when all these bugs still exists.

By the way, I would say the same thing to Microsoft about Visual Studio itself. Of course, they probably realise that if they ever released a version of VS.NET that JUST WORKS nobody would ever upgrade again. :)

21 comments
Comment actions Permalink

full ack :)

0
Comment actions Permalink

evgeny0 wrote:

ReSharper is a great product overall, but there are quite a few
annoying bugs to put up with. Please seriously consider spending A
LOT of time on a release that ONLY fixes bugs - no new features.
Sure, it would be an unconventional approach and your marketing
department will hate you, since you can't exactly put "has less bugs"
as a bullet point on the brochure, but I think your customers
(developers) will appreciate it.

It has enough features already. Quite honestly, I hardly ever find
myself thinking "I wish ReSharper did X" (some fancy new refactoring
or whatever). On the other hand, I find myself thinking all the time
"argh, I WISH ReSharper didn't leak memory so badly, I wish those
damn tool windows would stay where I put them, I wish it Unit Test
Runner would build the solution when needed and not build it when not
needed, I wish I could switch between Debug and Release
configurations, I wish IntelliSense would work first time when I type
'override'", etc., etc.

I think it's worth noting that the JetBrains support staff are great
and genuinely do their best to help with problem. At the end of the
day, however, there's only so much they can do to keep a customer
happy when all these bugs still exists.

By the way, I would say the same thing to Microsoft about Visual
Studio itself. Of course, they probably realise that if they ever
released a version of VS.NET that JUST WORKS nobody would ever
upgrade again. :)


+ 1 for that

--
Peter Sulek
terrorix@centrum.sk
XanaNews ver. 1.18.1.6

0
Comment actions Permalink

Ditto.

More speed and less memory.


"evgeny0" <no_reply@jetbrains.com> wrote in message
news:26335896.1176251977577.JavaMail.itn@is.intellij.net...

ReSharper is a great product overall, but there are quite a few annoying
bugs to put up with. Please seriously consider spending A LOT of time on a
release that ONLY fixes bugs - no new features. Sure, it would be an
unconventional approach and your marketing department will hate you, since
you can't exactly put "has less bugs" as a bullet point on the brochure,
but I think your customers (developers) will appreciate it.

>

It has enough features already. Quite honestly, I hardly ever find myself
thinking "I wish ReSharper did X" (some fancy new refactoring or
whatever). On the other hand, I find myself thinking all the time "argh, I
WISH ReSharper didn't leak memory so badly, I wish those damn tool windows
would stay where I put them, I wish it Unit Test Runner would build the
solution when needed and not build it when not needed, I wish I could
switch between Debug and Release configurations, I wish IntelliSense would
work first time when I type 'override'", etc., etc.

>

I think it's worth noting that the JetBrains support staff are great and
genuinely do their best to help with problem. At the end of the day,
however, there's only so much they can do to keep a customer happy when
all these bugs still exists.

>

By the way, I would say the same thing to Microsoft about Visual Studio
itself. Of course, they probably realise that if they ever released a
version of VS.NET that JUST WORKS nobody would ever upgrade again. :)



0
Comment actions Permalink

I agree with this. Please stop adding cool new features just for the features. Please, please, please fix the bugs, get R# to run fast (even on big source files) and with little memory, leave the memory to the developer to debug and run.

As said many times before, R# is great but it's come to the stage now that a lot of us can't use it anymore due to the size it takes up. It's time for a diet for R#.

Patrick

0
Comment actions Permalink

I agree with this! Please invest in bug fixing of v2.5 !!
- CamelHumps navigation (Ctrl-Arrows) has never worked
- Inserting from clipboard destroys code formatting of braces
- support for generics is buggy (Ctrl-Space on generic method inserts
brackets but not the "<...>")


Sincerely,
Stefan Lieser

0
Comment actions Permalink

Fix the bugs, pls

0
Comment actions Permalink

How many votes do I get to cast for those TWO NEW features ??

I just installed EAP build 376 and R# takes MORE memory than build 337 !
Fellas, I hate to break it to you, but that's a big step BACKwards.

In the phrasing of my people......Oy Vey


"john" <xx@xx.xx> wrote in message news:evia0n$4lq$1@is.intellij.net...

Ditto.

>

More speed and less memory.

>


0
Comment actions Permalink

Stop crying you all and buy more memory!(ow yes and stop using typed
datasets) ;-p

I enjoy all new R# features I never knew I missed :)


evgeny0 schreef:

ReSharper is a great product overall, but there are quite a few annoying bugs to put up with. Please seriously consider spending A LOT of time on a release that ONLY fixes bugs - no new features. Sure, it would be an unconventional approach and your marketing department will hate you, since you can't exactly put "has less bugs" as a bullet point on the brochure, but I think your customers (developers) will appreciate it.

It has enough features already. Quite honestly, I hardly ever find myself thinking "I wish ReSharper did X" (some fancy new refactoring or whatever). On the other hand, I find myself thinking all the time "argh, I WISH ReSharper didn't leak memory so badly, I wish those damn tool windows would stay where I put them, I wish it Unit Test Runner would build the solution when needed and not build it when not needed, I wish I could switch between Debug and Release configurations, I wish IntelliSense would work first time when I type 'override'", etc., etc.

I think it's worth noting that the JetBrains support staff are great and genuinely do their best to help with problem. At the end of the day, however, there's only so much they can do to keep a customer happy when all these bugs still exists.

By the way, I would say the same thing to Microsoft about Visual Studio itself. Of course, they probably realise that if they ever released a version of VS.NET that JUST WORKS nobody would ever upgrade again. :)

0
Comment actions Permalink

Stop crying you all and buy more memory!


For the record it doesn't matter. R# currently falls over WELL before most of us are out of physical memory. :(

0
Comment actions Permalink

+1 to Jeremy's comment.....

"Jeremy Gray" <no_reply@jetbrains.com> wrote in message
news:32381808.1176488158216.JavaMail.itn@is.intellij.net...
>> Stop crying you all and buy more memory!
>

For the record it doesn't matter. R# currently falls over WELL before most
of us are out of physical memory. :(



0
Comment actions Permalink

Hello everyone,

I'd like to clarify what is going here in ReSharper team on features, bugs
and such. I'm going to talk about version 3.0, just because 2.5 release was
all about performance and memory optimizations as well as general UI cleanup
and better VS integration. Yeah, we couldn't resist to add few nice features,
like value analysis and go to file member. These new features saved a lot
of time and prevented lots of bugs, and I hope not only for ReSharper project.
Anyway, 2.5.2 bugfix update is about to be released next week. Did you try
Release Candidate?

Version 3.0 gives many of the ReSharper features available for C# developers
to VB.NET community. Does it mean we've stopped C# bugfix and development?
Not at all. Many subsystems inside ReSharper are improved and fixed, while
we are working on VB.NET support. We also work hard to improve VS integration
and this includes commands, tool windows, menus, solution load time and so
on. We are working on refactorings for VB.NET, but this also means that many
issues with them in C# are revisited and fixed, or eliminated during engine
improvement process. We are working on search and navigation features for
VB.NET, and it also means problems in this area for C# are analysed, fixed
or improved. So, is this bug fixing or is this feature building?

It is often hard to say if particular issue is a bug or a feature. For example,
many people who tries ReSharper for the first time complain that ReSharper
"breaks intellisense". Does it? It behaves different to Microsoft style,
and often is much better. Once you learn ReSharper intellisense, you can't
use VS native one - it is way too limiting. However, we understand that people
do like their habbits and are going to implement VS-style-ReSharper-power
intellisense in 3.0. Once again, is it about fixing bugs or about new features?

I admit, ReSharper has a number of nasty problems, pursuing us from version
to version. They include OutOfMemory exceptions, naughty tool windows, solution
synchronization problems and some others. They are still there, does it mean
we don't spend time with them? No! Each release, each EAP build, each milestone
we fight them. Sometimes we have results, sometimes the problem beats us.
Why is so? Because we can't reliably reproduce most of them.

If it were something like "open this project and you get OOM", we would have
spend time - any time needed - and find the source of the problem. Rarely
we get OOM with ReSharper solution itself, but next time you open it, armed
with memory profiler, debugger or whatever - it just doesn't happen. We have
a lot of information about why it could happen, but nothing about why it
happens. And we do know, that it has nothing to do with real memory, it is
more likely to be something about COM/Native interop. Several people informed
us, that they have project which always causes OOM, but they can't send it
to us due to various reasons, be it top-secret commercial research or just
management in the way. Do you have such project, which you can send us for
investigation?

I'm not going to explain the current situation with all such bugs, it would
take a lot of time but not add any value to the reader - they are mostly
technical details about Visual Studio integration. I just want to assure
you, we spend a lot of time on bugs, on speed, on memory usage. Unfortunately,
results are not always immediate improvements, but instead a small step on
the way to a better tool. Every great journey starts with a small step, you
know :)

After all, if we stop making new features, who will lead productivity tools
camp to make developer's live better? :)

PS: You are welcome to open separate topic for each problem that causes you
to loose productivity with ReSharper, we will discuss it thoroughly.

Sincerely,
Ilya Ryzhenkov

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

Hi Ilya

Let me start by stating that I love you product. But I am very troubled by
the OOM problem. I am also limited by coporate policy and cannot send our
bits to you guys. Having all these things in mind I still would like to help
you guys on fixing these issues. So ... what can I do?

Which kind of analysis would you like? Can you provide / recommend some
kind of analysis that you guys can use?

Sincerely yours
Torkil @ IBM

"Ilya Ryzhenkov" <orangy@netix.ru> wrote in message
news:9f6b3e291375168c94cba0c95c9df@news.intellij.net...

Hello everyone,

>

I'd like to clarify what is going here in ReSharper team on features, bugs
and such. I'm going to talk about version 3.0, just because 2.5 release
was all about performance and memory optimizations as well as general UI
cleanup and better VS integration. Yeah, we couldn't resist to add few
nice features, like value analysis and go to file member. These new
features saved a lot of time and prevented lots of bugs, and I hope not
only for ReSharper project. Anyway, 2.5.2 bugfix update is about to be
released next week. Did you try Release Candidate?

>

Version 3.0 gives many of the ReSharper features available for C#
developers to VB.NET community. Does it mean we've stopped C# bugfix and
development? Not at all. Many subsystems inside ReSharper are improved and
fixed, while we are working on VB.NET support. We also work hard to
improve VS integration and this includes commands, tool windows, menus,
solution load time and so on. We are working on refactorings for VB.NET,
but this also means that many issues with them in C# are revisited and
fixed, or eliminated during engine improvement process. We are working on
search and navigation features for VB.NET, and it also means problems in
this area for C# are analysed, fixed or improved. So, is this bug fixing
or is this feature building?

>

It is often hard to say if particular issue is a bug or a feature. For
example, many people who tries ReSharper for the first time complain that
ReSharper "breaks intellisense". Does it? It behaves different to
Microsoft style, and often is much better. Once you learn ReSharper
intellisense, you can't use VS native one - it is way too limiting.
However, we understand that people do like their habbits and are going to
implement VS-style-ReSharper-power intellisense in 3.0. Once again, is it
about fixing bugs or about new features?

>

I admit, ReSharper has a number of nasty problems, pursuing us from
version to version. They include OutOfMemory exceptions, naughty tool
windows, solution synchronization problems and some others. They are still
there, does it mean we don't spend time with them? No! Each release, each
EAP build, each milestone we fight them. Sometimes we have results,
sometimes the problem beats us. Why is so? Because we can't reliably
reproduce most of them.

>

If it were something like "open this project and you get OOM", we would
have spend time - any time needed - and find the source of the problem.
Rarely we get OOM with ReSharper solution itself, but next time you open
it, armed with memory profiler, debugger or whatever - it just doesn't
happen. We have a lot of information about why it could happen, but
nothing about why it happens. And we do know, that it has nothing to do
with real memory, it is more likely to be something about COM/Native
interop. Several people informed us, that they have project which always
causes OOM, but they can't send it to us due to various reasons, be it
top-secret commercial research or just management in the way. Do you have
such project, which you can send us for investigation?

>

I'm not going to explain the current situation with all such bugs, it
would take a lot of time but not add any value to the reader - they are
mostly technical details about Visual Studio integration. I just want to
assure you, we spend a lot of time on bugs, on speed, on memory usage.
Unfortunately, results are not always immediate improvements, but instead
a small step on the way to a better tool. Every great journey starts with
a small step, you know :)

>

After all, if we stop making new features, who will lead productivity
tools camp to make developer's live better? :)

>

PS: You are welcome to open separate topic for each problem that causes
you to loose productivity with ReSharper, we will discuss it thoroughly.
Sincerely,
Ilya Ryzhenkov

>

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

>



0
Comment actions Permalink

Hello Torkil,

Thank you for supporting us in our battle against OOM. We think that it is
not real low memory condition, but rather some unmanaged component (COM or
native), which raises STATUS_NO_MEMORY SEH exception, which is then converted
to OOM by CLR. It also can be E_OUTOFMEMORY returned as HRESULT. It seems,
that STATUS_NO_MEMORY is raised during some CLR housekeeping, or during native
call or COM interop on other thread, and then somehow marshalled as OOM to
different thread by CLR.

The only idea I have is that you run VS with debugger attached (e.g. another
DevEnv instance), enable first chance exception catching (Debug | Exceptions...)
for just OutOfMemoryException (put checkmark near System.OutOfMemoryException
in Common Language Runtime exceptions | System) and try to load your solution.
As soon as you hit OOM, open Threads window, go through each thread and copy
every stack trace you happen to see. Send this stack traces to me by email.
May be we can see faulting interop call on the other thread...

Sincerely,
Ilya Ryzhenkov

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

Ilya, thanks for your long and detailed reply. To some degree, I understand exactly what you mean, but to some degree I also think you're avoiding the issue. It's hard to believe that ALL the annoying ReSharper bugs haven't been fixed simply because they couldn't be reproduced. I'm sure that many of them haven't been fixed because there is no time to fix them, which is because the developers are busy adding new features. That was the whole reason for this thread.

If being unable to reproduce bugs is really the main problem then I have two suggestions:

1. Post a list (in some highly visible place, not this thread) of the top-priority bugs that you cannot reproduce for users to see, so that people know exactly which bugs are not being fixed for this reason and can help with them. JIRA comments often don't mention this, so I simply assume nobody has gotten around to looking at that bug.

2. Accept that not all bugs can be reproduced "in the lab" and some will have to be debugged "in the field". That means investing a lot of developer time into building a lot more diagnostics into ReSharper. It already submits unhandled exceptions to JIRA, which is great, but obviously it only helps with some types of bugs and not others. For example, you could build a small EXE that automatically attaches to VS.NET as a debugger on start-up (when running in "troubleshooting mode") and writes a memory dump on first-chance OOM. It's a bit too much to expect customers to run VS.NET under the debugger all the time if that debugger needs to be started manually, takes a lot of memory and slows down their development, but they may well do it if it's as simple as supplying a command-line parameter and there's no noticeable performance loss. If unmanaged memory leaks are a problem then build code into the unmanaged parts of ReSharper that reports its detailed memory usage on demand. And so on... Sure, none of this is simple, but you've already fixed the stuff that's simple. Now it's time to fix the difficult bugs and really make ReShaper a solid product.

0
Comment actions Permalink

Ilya, if the faulting project cannot be sent to you, perhaps you should visit the faulting project instead? That means, fly to a developer's shop in person, armed with whatever debugging tools you need, and debug the project there? Of course, you would have to spend on an airline ticket and perhaps a hotel stay, but it might well be worth the effort. Of course you should only do this with a customer who regularly and reliably has OOM or other problems not reproducable in your lab. Often, with this technique, you are much faster than trying to reproduce bugs for weeks with no real result.

Many shops who cannot send you their source code for security reasons will happily assist you with this approach.

Best regards,
Urs

0
Comment actions Permalink

Hello,

For some reason my previous email address was used in newsgroups, please
don't send emails to it. This post should have correct email address, please
use it if you are going to send any stacktraces. Thanks.

Sincerely,
Ilya Ryzhenkov

JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

Just a thought - another option be for the good folks at JetBrains to create some option we could turn on to force ReSharper into a "diagnostic" or "verbose debugging" mode that could capture the metrics and any other useful info to tackle problems like this memory issue.

The "dump" of this could then be uploaded to JetBrains for their analysis without any of the content that users may not be willing/able to share.

Kirk

0
Comment actions Permalink

I have to second this.

A long time ago, in another life, our company decided to adopt a development
tool and was experiencing a weird issue/problem. It was killer for us, but
the developers of the product couldn't reproduce it. They send someone to
our place of business and waited around for the problem to occur, and when
it did, they jumped on it, saw immediately what the problem was, and had us
a fix in just a few days. It was amazing how much time was saved. It
seemed 'expensive' up front, but it probably saved tons of money in the long
run, compared to either having us reject the product because of the problem,
or spending weeks and weeks trying to get them to reproduce the problem.


"Urs Eichmann" <no_reply@jetbrains.com> wrote in message
news:14062753.1176704526885.JavaMail.itn@is.intellij.net...

Ilya, if the faulting project cannot be sent to you, perhaps you should
visit the faulting project instead? That means, fly to a developer's shop
in person, armed with whatever debugging tools you need, and debug the
project there? Of course, you would have to spend on an airline ticket and
perhaps a hotel stay, but it might well be worth the effort. Of course you
should only do this with a customer who regularly and reliably has OOM or
other problems not reproducable in your lab. Often, with this technique,
you are much faster than trying to reproduce bugs for weeks with no real
result.

>

Many shops who cannot send you their source code for security reasons will
happily assist you with this approach.

>

Best regards,
Urs


0

Please sign in to leave a comment.