- Know-how score: Indicates a developer's breadth of knowledge in the analyzed software and scored on a 1-to-10 scale. The whole score combines developer's unique and shared know-hows. While the former illustrates the knowledge possessed only by this developer, the "shared know-how" indicates knowledge shared with other team members.
- Size of personal contributions: Uses the code’s syntax to measure size in terms of code statements rather than a less accurate, format-dependent count of lines of code.
- Complexity: Uses multiple software metrics to measure complexity of the code produced by the developer.
- Activity: Indication of developer or team activity during the 2 week period of time. It measures the number of components and frequency of modifications made to them by the given developer (or team).
News: SourceKibitzer EyeQ released
SourceKibitzer has announced EyeQ, an advanced analytics solution to add transparency into multi-location software development teams. SourceKibitzer EyeQ provides you with bi-monthly reports containing objective information about contribution, know-how and expertise of distributed software teams and all that in a handy PDF format. Instead of tracking hours and tasks or evaluating software quality, EyeQ reports revolve around developers' knowledge and expertise. Importance of these indicators is greatly undervalued by modern analytics tools. The SourceKibitzer EyeQ solution is targeted at overcoming this by providing indicators useful not only for software specialists, but even more for high-level managers and customers of software development houses. The higher-level contributor indicators found in each report include:
- Posted by: Mark Kofman
- Posted on: December 10 2007 08:22 EST
- Re: SourceKibitzer EyeQ released by Nikita Ivanov on December 10 2007 14:53 EST
- I prefer a culture of mutual trust to tools by Carl Rosenberger on December 10 2007 14:53 EST
Guys, Site's down.... Regards, Nikita Ivanov. GridGain - Grid Computing Made Simple
Some experiences from the way our distributed open source team works: - A distributed team is most efficient if knowledge is distributed, if ownership is shared and if members of the team teach eachother. For this purpose we believe in a culture of extensive remote pair programming. Management focus on maximizing the output of individuals inhibits strong teamplay. - The number of lines of code changed is not an important metric and certainly none that managers without hands-on-coding knowledge can judge well. The work done to hunt down a blocker bug can take more time and be more valuable than a refactoring session that changes the name of 500 classes. - We believe in a culture where people like to work. If people are a fit for our team, we don't have to control and micromanage their work output. We do planning sessions at the beginning of each week to assign a workload to each of us that can be accomplished. If tasks do not get done, they will be talked about at the weekly review meeting. - Simplicity, readability and quality of the produced code are key for maintainability. A tool will have a hard time to understand if 30 new classes (well written, small methods, no circular dependancies) were something good or if the 15-liner someone else wrote to do the same thing was better. After all these skeptical comments, I will still take a look if this tool adds something useful on top of the commit notifications and Fisheye views I am happy with at this time.
Carl, Very nicely put! Common sense but so rarely expressed... I looked at SourceKibitzer, spoken with Mark about it and can certainly recommend to look at this tool. Best, Nikita Ivanov. GridGain - Grid Computing Made Simple
Some experiences from the way our distributed open source team works:I agree to your point that culture and trust is important in software development. It becomes even more critical when you work in distributed teams. Goal, of our tool was not to replace the culture, but instead to support it with higher level visibility and better information about team members.
- A distributed team is most efficient if knowledge is distributed, if ownership is shared and if members of the team teach eachother. For this purpose we believe in a culture of extensive remote pair programming. Management focus on maximizing the output of individuals inhibits strong teamplay.
Commenting importance of knowledge distribution. For this purpose we have a very detailed view on each developers product know-how. To be able to share knowledge, you have to know who holds it in hand. If few developers team it's easy. But managing knowledge in big enough distributed software teams could benefit a lot from automated tools like EyeQ. Mark http://www.sourcekibitzer.org/Bio.ext?sp=l8