Saturday, June 04, 2011

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.