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.

Why community driven open source teams produce high quality software?

A community driven open source project is an open source project that is completely driven by an online community of developers where there is no organizational structure. Developers are contributing on their own time without getting paid except maybe donation. Also, they are free to leave the project at any point. Why would such projects produce many times higher quality software than closed source software project developed by teams with scientific management and stringent accountability?

• 
  No politics. Everyone is truly for the good of the project, nothing else. For example if someone feels that a refactoring is needed, he will just do it without worrying if he should focus on features development so that velocity looks good.
  


• 
  Better recruiting process: 1) only people really love the project will try to get on the project, 2) skill can be tested again and again thru the patches new candidates submit. In another sentence, candidates are evaluated by the real work they do on the project and no bias of any kind. This process can take as long as needed since in the same time the candidates are contributing the project.
  


• 
  Developers are forced to focus on good code quality. Because every single line of code needs to be highly consumable by other committers who, when they need to continue this work, usually don't have the context and may never get the chance to talk to the developer who wrote it. Readability and tests are absolute must-haves, because that's all other developers can count on.
  


• 
  More sense of achievement because the well designed code can be appreciated by a much broader audience in an open source project. Some say that programming is like art (and I believe they are talking about the code not the front end UI), then artists certainly appreciate more recognition of their work.
  

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.