Fog Creek Software
Discussion Board




How does productivity get measured where you work?

I always here academics railing against using  lines of code as a measure of productivity, but I have never actually worked for a company where productivity is measured this way.

Places I have worked, productivity was measured by either a) reputation (how long has it been since you did or fixed something cool)

b)the difference in bugs fixed versus committed

c)a mix of What skills you have vs what the company needs and a rough evaluation of you by your manager

Do other companies have more formal systems? please share.

Daniel Shchyokin
Thursday, May 08, 2003

Certainly my last company didn't measure productivity very well.

Which person is more productive? One person that completes 6 small projects, fixes tens of other peoples' bugs and gets woken up all the time for emergency problems in 1 year or another person that completes 1 cool project in the same time?

Well under the evil and capricious rank and spanking system, the person that does the 6 small projects and fixes lots of bugs caused by OTHER people will get measured as being worth less because the chances of having 1 out of 6 project managers saying one thing bad about you is higher than just 1 project manager that has known you for a year!

Also I've found people that do very little and don't attract any attention will get rated higher than people that do lots.

FunnyCodeMonkey
Thursday, May 08, 2003


My experience has been just the opposite... the guy with all the activity, even if it is running around in his own little circle rut would be rated more productive.

And of course, the project manager with one small project that takes a year or more to complete with multiple productive people (as measured by the above) will be judged more valuable than anyone.

Most places really don't measure anything.

Joe AA
Thursday, May 08, 2003

People are not commensurable. Or are they?

YF
Thursday, May 08, 2003

We measure productivity by the number of breakdowns in the company.  If one person doesn't get signed-off with stress each week well dammit we aren't really being productive....

Sherlock

sherlock_yoda
Thursday, May 08, 2003

Daniel Shchyokin :

Line of codes measure was OK when most people were still coding in assembler, a few decades back.

Development tools have not evolved,
from your favourite IDE you can just now select
a wizard and the thing will generated for you
thousands of lines of code.

measuring lines of code produced is no longer the way to determine a programmers productivity

Codex
Thursday, May 08, 2003

I wrote some code today. I'm very productive.

Stephen Muires
Thursday, May 08, 2003

I documented some code I wrote yesterday.

Hear me roar.

Danil
Thursday, May 08, 2003

The only thing that looks like a productivity measure overhere is that I get 4 to 6 objectives to do for the year. We have a mid-year meeting to to an re-evaluation. Then at the end of the year we calculate that my bonus is equivalent to the percentage of objectives met. I got 100% this year so I get a 100% of my bonus (~10% of my salary).

Application Specialist
Thursday, May 08, 2003

Similar as App Specialist:  Every 6 months we create a list of tasks for each person to accmoplish.  Each 6 months the review takes place based on those tasks.  Usually, I can itemize more than the listed tasks, as it requires more than the expected work to get the product out.

The most important tool I have for this is my weekly status report - which my manager does not require.  At the review period, I just grab the pile since the last review, copy/paste, instant review summary - with dates if I need them.

Nat Ersoz
Thursday, May 08, 2003

Measuring productivity per person is probably a bit dicier than measuring it for a whole organization. Of course, the numbers you come up with aren't necessarily very significant, but their change over time certainly is. In a given organization if the tools remain relatively the same over a period of time and the numbers you generate are normalized in some form to account for the number of resources working on it, I believe that LOC or bugs-generated or other standard metrics have a lot of meaning.

It seems like the cardinal rule of metrics is always to calculate a metric, within an organization, in the same way.

Jeff Kotula
Thursday, May 08, 2003

Measuring lines of code was always a horrible metric.

Suppose two people are writing different algorithms to do the same thing in assembler... One person might write a five hundred line solution to the problem and another might write a one hundred line solution that solves the exact same problem just as well, except the LOC are smaller.  The smaller version is often likely (especially with assembler) to be a lot faster, more efficient and more elegant than the 500 line version, not to mention it will likely be much more easily maintainable.

In my experiece, a well-managed company doesn't need to use a specific metric for performance.  If the managers don't have a good common-sense "feel" for how productive each of their direct reports is, something is hopelessly screwed up at that company.

George McBay
Thursday, May 08, 2003

Is your butt in the chair, and are you typing?

no, really
Thursday, May 08, 2003

Jeff, you must be kidding. A good designer will actually spend time modularising code, which *reduces* code size, sometimes substantially.

This type of code is of much higher quality, and cheaper to maintain down the track.

Any companies that measure LOC are by definition stupid.

How would it look assessing building architects by number of bricks used. Doctors by number of drugs dispensed. I can see the possibilities if we can just get some good MBA-edcuated project managers in some of these other industries.

.
Thursday, May 08, 2003

Productivity implies too much of a measure of efficiency - I think it's far more important to measure effectiveness.

As a project manager I don't care how many lines of code, face time or whatever - I want to reward people for spending time doing the right things, doing them well and contributing to the overall company objectives (whatever they may be)

Like somebody else mentioned here, I think setting individual personal goals on a 6 monthly/yearly basis and measuring against that is a good idea. I would couple that with measuring against company core objectives/initiatives.

So I guess in conclusion I don't think measuring productivity per se is a good idea at all. In fact don't people find it devaluing? Surely it's like working in a car assembly plan to something, having to add 5 pieces a minute to the car or something.

Yanwoo
Friday, May 09, 2003

Lines of code are useful only for measuring cost and effort, but not for measuring productivity.

The most productive programmers don't produce more by writing more lines of code per day than everybody else; their productivity comes from getting the same job done with LESS lines of code.  There isn't a huge disparity in lines of code per day from one programmer to the next.  So while 1000 lines of code will usually take a good progammer and a crappy programmer the same number of days, in those 1000 lines the good programmer will have created several times the functionality as the crappy programmer, and with fewer defects.

T. Norman
Friday, May 09, 2003

I'm going to take a position against the "personal goals in the 6month/anual review process" (hereafter called "personal goals") method of measuring productivity.

The problem with doing it this way is:
If the developer is in control of setting these personal goals, then all an unscrupulous developer has to do is set easy goals and bing-o! they're now the most productive programmer.

If the manager is in control of setting the personal goals, then the manager has now effectively taken project task scheduling responsibility away from the developers. Which is general agreed to be a Bad Thing.

And if it's a fight between the two, then you get some combination of two bad options. And no, something good doesn't come from that.

And before you ask, no, I don't have a good way of measuring productivity.

Bill Tomlinson
Friday, May 09, 2003

You can find problems with everything if you look hard enough. Setting personal goals is not perfect, but in my opinion is a very useful practice with a lot of benefits. Some people will always take the p**s, but you can't not use a practice just because the minority abuse it.

People who can't take this seriously wouldn't last long (and theoretically would never be employed) in a company where this was a core part of the culture.

Yanwoo
Monday, May 12, 2003

I think the best programmers are 100 or even 1000 times better than the average.  And the same applies to the average as compared to the bad.

I think the best programmers
(a) Write code that does more in less lines
(b) Write code more reusable code. If you write say a general function that gets re-used 100 times/cases, this in itself is 100 times more productive than writing say 100 special cases by duplicating near identical functionality.
(c) They write more (and better) code in the same time.  I keep hearing that average number of lines of code per day across programmers/companies is constant. Frankly I think this can not be true (from personal experience), maybe the measurements are too course.
(d) Get stuff more right first time. Partly this stems from (b).  Debugging say 1 function called from lots of places has got to be easier than say debugging 100 special cases of near duplicate code.

IMHO, lines of code is stupid measure as it runs both in favour and counter to what good programmers do.

Also IMHO, the story that lines of code per day = constant, so people who do more in less lines are more productive - is COUNTERPRODUCTIVE.  There is particular type of bad programmer who use pointers (usually packed into 1 line complex expressions) for every darn thing.  All their C code looks like *a++ = *++y+z^^*k-- or worse.  They are so focused on getting more done in less lines, that they use pointers even when they are not the most appropriate level of abstraction.

S Tanna
Tuesday, May 13, 2003

*  Recent Topics

*  Fog Creek Home