A readability monitor IDE plugin?

In large projects, developers spend a lot of time figuring out what is going on with the code before they can add functionality to it. For code base with poor readability, this activity cost a lot more and has to be repeated by multiple developers and sometimes the same developer multiple times (because human memory is short).

Is it possible to monitor the readability and its impact to the efficiency to the team? It might be achievable through monitoring the behavior of developers using development tools such as IDEs.
There are mainly two modes in which a user engages with an IDE
1) code browsing - user browse across the code base, quickly navigate between files and different parts of the file, during which user changes nothing.
2) code writing - user writes code, usually focusing on a small set of locations in the code base.

It shouldn't be too hard for an IDE plugin to differentiate the mode the user is currently in. For example, if the user hasn't change any code for a while but has been actively navigating thru the code base (such as switching between files, scrolling within them, searching and so on), he is probably in the reading mode. Otherwise if the user has been frequently writing code and running tests, he is probably in the writing mode. The plugin can then simply record the time period user spent in either modes, and provide reports of such behavior across the team.

Obviously, the ratio between the code reading activity and the code writing activity across the team would be an good indicator of the overall readability of the code base. Of course sometimes such indicator might be redundant since the quality of code might be measurable by other means. However this indicator can also provide (to the people with the money) some quantifiable cost of bad code, or in another word, technical debt. You can say something like 95% of the development coding effort is wasted in reading this spaghetti code base v.s. the same team only spend 50% on another similar sized project. You can also suggest something like if we spend X weeks, we can improve the code base so that we can improve the code writing efficiency by Y percentage for the Z weeks of future development.

A couple of tips for RubyMine performance optimization

Set aside the IDE vs editor topic, one of the biggest complains about RubyMine is its performance. In a large project, without tweaking it a bit, RubyMine could be so sluggish that it becomes simply unusable. That's probably the #1 reason many RubyMine users ditch it and go back to simpler lightweight editor such as vim or TextMate. Well, there are actually a couple of things that can significantly impact the performance of RubyMine. With a little care, RubyMine can perform with an OK smoothness.
1) By default, RubyMine's jvm max heap size bound is set as 512MB, it's probably be enough if you are running it on a 32bit JDK, but on a 64bit JDK, it might be necessary to bump it up to 1024MB, since the 64bit uses twice as much memory. This will reduce the number of GC collection. Here is some guide on how.
2) More importantly, RubyMine index everything in your project to support text search/refactoring etc. So if you have some huge files that also get changed very often, such as log, spec reports, etc, it could be very expensive to have RubyMine indexing them all the time. Exclude them from RubyMine project structure is probably a good idea.
That's it. I think with a little love, RubyMine can still be a valid ruby development tool, especially for people who are used to JetBrian's IDEs.