Journal Journal: How to define the productivity of a developer
I'd like to take my own stab at that topic...
There were many interesting remarks about what a productive developer is and I'd like to list one...
dwheeler states this:
This article starts from a misunderstanding, and then "discovers" that the misunderstanding isn't true. Yes, source lines of code (SLOC) aren't good measures of productivity; that's because they weren't intended to measure productivity. SLOC are useful for estimating development effort. The best programmers manage to simplify problems so that they can solve the same problem with less effort. SLOC can then be used to estimate that effort, before it's expended, or used to estimate the effort that was expended. Claiming that SLOC measures productivity is silly.
This comment touches one of the core problems when you try to measure productivity in line of code.
So, I would like to suggest a different approach:
In Multi-Dimensional Separation of Concerns, there is the notion of a concern.
A concern has been defined as "something that concerns software".
Within each piece of software, there are different concerns that needs to be satisfied... that includes the different requirements, tasks, constraints and technologies used. I don't want to go into that here... read about MDSOC and you'll see.
What ties this to productivity is something different...
Let's take an example:
During requirements phase of an application, 25 requirements are identified and until implementation starts they have been added to and been refined so that about 100 concerns have been identified.
These 100 concerns amount to 100.000 lines of code.
Measuring the productivity of a developer in lines of code is pretty pointless, as stated above, but measuring it in concerns satisfied might be something different.
Let me explain this:
Each concern within the concernspace of your application has a complexity rating attached. That complexity stems not from the LOC count but from the complexity of the concept this concern encapsulates.
Developer A who is able to solve 5 concerns with a complexity of 1 within a week is, imho, less productive than developer B which can solve one concern with a complexity of 6 in the same time.
If the work of A amounts to 5000 LOC and the work of B amounts to 1000 LOC, line-of-code-measuring would make A more productive than B.
He is not, imho. A produces more output, but (s)he tackles only the simple concerns, which merely require much code instead of much thought.
There are other appproaches to measure productivity, which are decoupled from the LOC count.
Most of these approaches are also decoupled from the units of interest (i.e. concerns) of the software.
beanerspace writes this:
For example. In grad school, we took the 1992, IEEE Standard for a Software Quality Metrics Methodology, along with GNU Flex, and wrote a program that would slice-n-dice C & C++ programs against a table of measureable metrics for code readability and reusability.
And he continues:
But we also noticed that there were just some things that it would never be able to test. For exmaple, while our little app spotted code that was uncommented, it could not tell us whether or not the comments were useful or relevant
This is a perfect example where the measurement is decoupled not only from the LOC but also from the concerns.
To stay within the example, to measure the impact of a piece of uncommented code, you have to take into consideration which concern it belongs to... to an important and complex concern or a less complex / less important concern.
If you spot bad / unproductive code in a complex concern, you have a large impact on the application as a whole, and such, a less productive developer, as the code is a possible source for trouble in the future.
And so, measuring the productivity with common tools and taking the concerns into consideration is a good start.
You can go further, though...
If you look at an application solely from the concern point of view and don't care at all about the metrics involved, you get a simple picture:
Developer A satisfied concern 1 to 5.
Developer B satisfied concern 6.
Due to the complexity of the concerns involved, A is awarded 50 points, B is awarded 60 points.
As long as the concerns need not be changed, that is the total.
Let's assume that later, concern 1 and 6 need to be changed.
The change to concern 1 (let's call it 1') impacts on about 20% of concern 1. As long as 1' is not more complicated than 1, it should not take more than 20% of the time it took to create 1.
The developer performing the change receives 20% of the 10 points the concern was worth initially.
If it takes longer to change the concern, this can have to reasons:
- It is a more complicated change.
- Concern 1 was not easy to change.
If the change is more complicated, the developer is awarded more points in productivity.
If concern 1 was not easy to change, developer A didn't work very well as he made it harder to change the concern. Thus, points are deducted from his productivtiy account.
Let's make an example:
- Developer A creates the concerns 1 to 5 at complexity 10
Developer A is awarded 50 productivity points (PP) - Developer B creates concern 6 at complexity 60
Developer B is awarded 60 PPs - Developer A changes concern 1 to 1'
That requires about 20% change at roughly the same complexity as 1. - Developer A is awarded 2 points as he finishes within 20% of the time he needed to write concern 1.
- Develoer B changes concern 6 to 6'
That requitres about 20% change. - Developer B needs 40% of the time he needed for concern 6.
Either 1' is more complicated than 1 or 1 is not developed well. - Developer B looses the surplus time of 20% in points, i.e. 12 points.
- Developer A has 52 PPs
- Develoer B has 48 PPs
Ok... I gotta stop here... there's money to be earned... Your comments please.
