productivity and profitability

[Ellen Zhao]

If 5 chairs can be made out of 2 m^3 raw wood, and every chair will be sold for 50 � and every m^3 wood costs 5 �, we say that the productivity in this business is 5/2 = 2.5 [Chairs/m^3] wood, and the profitability is (50� * 5)/(5� * 2) = 25. (Good deal, I'd like to make it. ).

This is a very simple example about productivity and profitablility. Real things are not always that intuitive. We've modeled the productivity and profitability of a super market in several ways, which all make good sense. Now the question comes: How do you measure the productivity and profitablility of a software developer? The profitability, I think, is easy to form, take it as [(the brutto or netto profit in � of the software one developed) / ( the salary in � the developer received during the development)]. Productivity is more tricky. (lines of programme a developer generated) / (time the developer invested) [lines / hour] is not a good model, for lazy ones can always copy and paste to generate millions of lines. (number of test-passed units)/(time the developer invested) [units / hour] is not a good model, neither. If developer A was working on extremely tricky units implementing BMP, and B was working on units like hello world. A couldn't finish a single unit in one day, B happily passed dazons in an hour...Second model is not fair! (Especially when the head of HR had completely no idea about the difference between A and B's works...) Then I was thinking about the information entropy (loosely speaking, here the entropy could be taken as complexity). Let's assume the total entropy of a project is 1, we can try to see how much entropy can a develop reduce to the whole project in a certain time period. Then how to quantify the entropy of a software project becomes the question, and this is by no means an easy task...

It seems that it's uninteresting to discuss the productivity of a software developer, let's just inspect her/his profitability. But...well, I confess I might have to answer it in exam, what do you think is the safest answer?
[ January 20, 2005: Message edited by: Ellen Zhao ]

[Helen Thomas]

Hire a good team and if they are happy at the end of the project and feel they have achieved something worthwhile that's profitability beyond money.

Of course there has to be money somewhere in the equation.

Somehow I don't think this answers your question. I think you need Map for this. Map understands the unhappiness - mobility - happiness cycle. Watching Map gives me a headache and yet I learn a lot.
[ January 20, 2005: Message edited by: Helen Thomas ]

[Ellen Zhao]

Originally posted by Helen Thomas:
Hire a good team and if they are happy at the end of the project and feel they have achieved something worthwhile that's profitability beyond money.

Oh Oh, we all know that programming serves for delight, for ornament, and for ability. But let's concentrate on money for now.

I think you need Map for this.

Sure, she's one of the most productive posters here in the saloon. I would also expect a speech from Mr. Thomas Paul, the winner of "highest productivity" here...

Watching Map gives me a headache
When? Where?? How??? I never knew that, Helen! I think she's been always dear to you?
Why don't you be good, and caculate some money too;
Why don't you do good, like some other girls do?
[ January 20, 2005: Message edited by: Ellen Zhao ]

[Helen Thomas]

Are you hijacking your own thread, Ellen ?

I like Map but not enough to Save her Soul. I have enough problem saving mine. By headache, I meant Map works very hard at many different subjects.
I think you should ask for this thread to be moved to the OO & D forum.
[ January 20, 2005: Message edited by: Helen Thomas ]

[Warren Dew]

One thing to keep in mind: just because you can't measure something perfectly, doesn't mean you shouldn't measure it at all.

In particular, imperfect measures of productivity like lines of code per day or bugs per hundred lines of code may not be good management measures - because if programmers are reviewed on that basis, they'll have incentive to do stupid things - but they can be very useful to the programmer himself.

For example, I often keep a bug log, and it's very useful in identifying times or types of code where I tend to write more bugs. That has caused me to alter my habits to avoid those bugs, for example by not writing code when I'm sick, because my bug generation rate when I'm sick goes up by an order of magnitude, and being extra careful on code that handles individual bits and bytes, because for me that code is more susceptible to bugs.

It's also useful to get more aggregated measures of productivity to determine if working conditions and tools can affect them. For example, it has been found that programmers who are not disturbed by noise are much more productive, and that the method of estimation used to set deadlines can affect productivity.

I recommend the book Peopleware for more on this subject. While the discussion is not genius, it is good, and the actual results from various studies are extremely worthwhile to know.

If you move the discussion, the Process forum may be more appropriate than the OO forum.

[Helen Thomas]

Yes, I agree with Warren that the Process Forum is best. And past performance is always the best indicator unless you are trying something rather radical and new.