3 ms·

I would say the best way is by the outcomes, by the results. By productivity - be it units produced, share price, value added... Productivity is not = hours wo

• ido 16y ago
  Yeah but that gets pretty vague pretty fast. How do you measure a programmer's productivity when you can't estimate exactly (and sometimes not even close) how much work something should take?
  • neeleshs 16y ago
    I have not seen a software project where there is not enough work for somebody. What I've found useful, and which worked reasonably well for teams which have been working over a period of time together is to collectively estimate complexity of tasks that must be completed.Say on a scale of 1-5. That gives you a reasonably agreeable scale of measurement (not a universal scale, but the one that the team accepts). As time progresses, you see how many such tasks are completed by any person in a given time frame. Not that this is foolproof, or that it works right from the beginning of a project, but over a period of time, you tend to get a good sense of how productive each member is. [Edit: Typo fixed]
    • ido 16y ago
      Sounds pretty decent, although there is still the problem that it doesn't tell you if someone is slacking off or is simply not very fast.
      • VBprogrammer 16y ago
        Nor does it tell you anything about the quality of the work produced. Sometimes a job half done is worse than a job never started!