On Feb 1, 9:11 pm, jr <[email protected]> wrote: > Hello Everyone, > > I have a question that might be a bit polemic. I would like to know > what approach do you take to measure productivity on a Java project. > If we speak just about lines of code, how do you measure them, how do > you filter non-redundant files from the redundant ones.
In general, people act how they are incentivized. So if you declare many lines of code as the measurements and good reviews and bonuses as the reward, your developers will produce duplicate code and write very short lines. If it's as few lines of code as possible, you'll see lines that are hundreds of characters long. If it's the least amount of bugs, developers will dispute all sorts of issues as invalid and lump twenty issues into one bug. If it's the most bugs solved, then you'll get a bug for every typo. If it's sign-up bonuses, then they'll start lending money to house buyers that can't afford to pay them back. Wait, that was the wrong industry! ;-) Anyway, you get the point. Now what is it that you really want? In general, people want to ship software that fulfills the client needs, is on time and on budget. Why not use that as the measurement for your team's success? Sure, there's plenty of things outside the control of your team (like the features that the marketing guys promised, the downtime caused by the operational guys or the buggy library that they need to program around), but for these obstacles and problems, you _want_ your team to tell you. So I think this is the best way you can get everybody to pull into the same direction - and the right one at that. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
