How Fast Does Your Developer Go? Measuring Productivity Metrics With Programeter

Within Project Management we use a lot of metrics. The metrics will provide some relatively objective “description” on how the project is doing. They are the Project Managers’ seismometer, they record if your project world is rocking, and how hard. Traditionally our metrics are focused on time and money. But how about that all important resource, the developer? Programeter is a tool that provides “meaningful productivity metrics”. That sounds intriguing enough to have a chat with Mark Kofman, CEO of Programeter.

1. Programeter is a tool that measures “meaningful” productivity metrics. What do you measure and why is it considered “meaningful”?

First of all, it is important to mention that Programeter is focused on measurement of teams and individuals. In contrast to many other measurement tools in software development we do not measure quality of the code. We try to provide information about the most valuable resource in the software development and it is developers themselves. There are two important aspects which Programeter is measuring. It is CONTRIBUTION and KNOW-HOW.

Contribution Indicators

• Contribution Size illustrates the size of code produced by the developer during the reporting period. Size is measured in lines of code and takes into account new lines added by the developer, lines that developer has modified and lines that he has deleted.
• New Code is the number of new lines of code that developer has added during the reporting period.
• Modified code is depicted by two indicators, namely “other” and “own”. These indicators represent amount of lines of code modified by the developer during the reporting period. If the developer has modified a line of code created by someone else, then the indicator “other” is increased by one. And if he modifies a line created by himself, then the number “own” is increased accordingly.
• Deleted Code is traced in a same manner as modified code, by two indicators “other” and “own”. They keep the count of lines of code deleted during the reporting period. Each deleted line increases either indicator “other” or “own”. If developer deletes his own line of code then the indicator “own” is raised by one. If the deleted code was created by someone else, then the indicator “other” is raised consequently.
• Active Days illustrates the number of days when developer was making code contributions.
• Activity developer’s or team’s activity during 1 month. It measures the number of components and frequency of modifications made to them by the given developer (or team).
  

Know-How Indicators

• Know-How Score illustrates the breadth of the developer’s knowledge in the project. The value is measured on the scale from 0 to 10. For example, the know-how score of 6.5 in certain project, means that developer is capable of working alone with most project components.
• Fresh Know-How represents the knowledge that was refreshed during the reporting period. For instance, if developer A has developed component “C” in the product and he has done changes to this component during last month, then it will be counted in his fresh know-how.
• New Know-How measures only knowledge that was introduced during the reporting period. For instance, if developer A has created new component “C” in the product during last month, then it will be counted in his new know-how.
• Unique Know-How similar to know-how score, but measures only knowledge that is NOT shared with other team members. For instance, if developer A has developed component “A” in the product and nobody else contributed to this component, then it will be counted in his unique know-how.
• Shared Know-How similar to know-how score, but measures only knowledge that is shared with other team members.

Why our metrics are meaningful? The key goal of our R&D is to make sure there is a way to apply our metrics in real-life. Instead of bringing mathematical proof I will give you an example:

Programeter has a metric called “know-how”. This give you the numeric representation of one developers breadth of knowledge in given product/project. We also can identify “unique know-how” which tells how much of know-how is unique to this developers. By unique we mean that only this developers to those components. Now lets imagine, there is developer in a team which has unique know-how 2.0 (20%) in project A. Now if the person with unique know-how of 2.0 goes away project and resource manager have good idea of how much they loose. They also turn to Programeter to find out which component were developed by leaving employee to make sure know-how transfer will happen efficiently.

2. Every team member can view the performance and contribution of the other team members. This can empower people to help each other out and focus on the overall team performance. What are the experiences so far? Does this actually work?

We are still in private-beta, so it is too early to do conclusions. Actually, that is the reason we wanted to outreach developers community so anybody could share their opinion whether it can really help you out.

One interesting example shared with us by one of the developers trying out the Programeter. He has used his profile reports to negotiate the salary with his manager. He used the report to convince his boss, that he deserves better salary. Without the Programeter reports he would lack any reasonable tool to proof that he is right.

3. Metrics can also be used to “do evil“. What are the characteristics of the companies / organization where this concept might not be effective?

There are so many tools that in hands of uneducated or inexperienced people that could be used as “weapons”. What we always tell to our users is that be sure to think carefully when interpreting the indicators. Metrics are often the reason to ask new questions. Those helps you to identify problematic situations, which you would miss otherwise.

So if you ask, which company would be the best users for our tool. It is the team with smart programmers, smart project managers and experienced top level management. They would get the biggest benefit. I would not suggest to implement the measurement system in a company which is stressed by low-quality, constantly missed deadlines and too emotional employees.

4. What is “The” story you tell at a diner conversation to illustrate the power of Programeter?

Imagine you have a big software development team. Lets say 100 developers. Would you agree that 20% of this team is not used to full-throttle? Usually the reasons for that are poor management, poor expertise, miscommunication, emotions, … Programeter would allow you to identify those 20% correctly and give them another project where they would be able to show-off the full productivity. So you can achieve the same result with smaller team. It give benefits both for programmers and managers. Programmers become valued at new project and managers can better manage the rest of the team.

More information about Programeter can be found on their site.