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.
There are two ways to develop software: the wrong way and the fun way.
Showing posts with label code quality. Show all posts
Showing posts with label code quality. Show all posts
Saturday, June 04, 2011
Wednesday, May 18, 2011
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.
Subscribe to:
Posts (Atom)