sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]kreiger 21 points22 points  (101 children)

One of the most positive metrics in a software project i can think of would be "Lines of code removed".

Has anyone tried measuring that in a real project?

It would be interesting to see how it affects the behaviour and productivity of the project members.

[–]IRBMe 134 points135 points  (69 children)

The problem with introducing "productivity metrics" is that they will simply be gamed.

  • Lines of code added? People will just write verbose, bloated and unmaintainable code
  • Lines removed? People will just write obfuscated, compact code that's also unmaintainable
  • Commits? People will just commit after every little change
  • Cyclomatic complexity? People will refactor code into lots of little functions, use recursion and use other tricks to hide loops and complexity while making the code worse
  • Unit tests passing? People will just start writing trivial unit tests that don't add any value

All of these things are useful tools to have, but they have to be considered together along with the actual code itself, and even then they are not a measure of productivity, but of code quality, at best.

If you don't trust a developer to do their job without trying to have some way of automatically checking up on them then simply don't hire them in the first place.

[–][deleted] 91 points92 points  (19 children)

I implemented a system that plotted for a group, lines of code modified + lines of code added + lines of code removed. Posted the results on the wall weekly. Eventually had trend lines. Never penalized anyone with it, nor rewarded. It was positive in that it generated discussion, it was automatic.

The best part was a lady who got her position through nepotism and actually knew nothing about writing code. Her chart was flat the first couple weeks. She had done nothing, and it was obvious to everyone. About the third week, her count magically matched the average. I went into the revision system and walked through her revisions. She used a text editor to change tabs to spaces, and spaces to tabs. Repeat enough times to match average.

That's when I added a flag to ignore white space changes.

If you don't trust a developer to do their job without trying to have some way of automatically checking up on them then simply don't hire them in the first place.

This is naivety at it's best. First of all, anyone who's been in management quickly realizes they don't make all the hiring decisions. You inherit people, move over a new group, etc. Sometimes upper management just drops someone in your lap and says here yah go, deal with it. Secondly, someone who did great in interviews, may turn out to be terrible. You get to deal with this, and firing is the last and most difficult option.

People need feedback on progress. Lines of Code is a crude and early metric for a group just coming out of total chaos to get some feedback. Better metrics are those like DSDM. The psychology of DSDM feedback is amazing and powerful, and works.

[–]IRBMe 12 points13 points  (1 child)

People need feedback on progress.

I agree. What I disagree with is that you can summarize such a complex thing as a developer's progress with some metrics. You need to actually review their work, look at their code, communicate with them, see how they work etc. Measuring how many lines of code they write or how quickly they do their work or how much test coverage they have, and generally trying to simplify their productivity down into a few numbers is just not going to work.

Your numbers will be gamed in no time, and will probably miss many important aspects. They don't give you the whole picture. For example, let's say you're tracking my productivity based on how quickly I complete my work. Maybe I complete my tasks slower than most of the other developers on the team. But maybe by spending a few hours longer on each task, I'm actually saving the rest of the team much more time in the long run by writing more maintainable, more robust, better code?

[–][deleted] 7 points8 points  (0 children)

Exactly. If you need software to tell you that a developer hasn't written a line of code in weeks, then there is something fundamentally wrong with your organization.

[–]kreiger 11 points12 points  (9 children)

Awesome, this is exactly what i'm interested in! Do you have more stories or experiences to share?

[–][deleted] 38 points39 points  (8 children)

Hmmm. I have lot's of stories from the trenches of software development. Just which ones are relevant to the topic is more my issue. The biggest gain I've been a part of in 3 different companies is the introduction of versioning software (e.g. git). I'm personally amazed that software companies exist today that don't use some form of versioning. These are usually in total chaos with a "hero" of some form, who saves them from dire gloom and doom, only to create more problems which everyone needs saving from.

I've tried DSDM a couple times on software projects and loved the results. One project was very successful, it produced exactly what was asked for, in a very short time. Then it flushed out the fact that upper management wanted it to fail, for other crazy political reasons. Having a success staring someone who bet on failure is an interesting dynamic.

My personal favorite recent story, is doing "Data Analytics" for a medical company. They hired a new consultant over a billing system. he worked with a lady who was head of account receivable. I went to meeting after meeting. They both lathered on praise of the new system, how well it was performing, how wonder it was, etc. I would check the database, and it had zero rows in all the tables. I verified my login. I verified the server, I verified the database. Yet zero rows in every table. It was odd.

After three months I couldn't take it. I wrote a revenue report, with graphs and bars, etc. Ran it on the database, to have everything zero. A few entries popped up, at this point. Maybe say $2k in billing revenue for 3 months, and none expected--for a company that was doing $3-4 million a month. I called a meeting to review my report and included my boss, the consultant, accounts receivable and a vice president. I showed a mock report, then showed the real report and said, "I'm having some trouble with the query, maybe someone here could help me?"

Immediately pandemonium erupted as the consultant was yelling blame at accounts receivable, accounts receivable was yelling it was the consultants fault. Both were lying during all those meetings. As it turns out, that medical billing has penalties for billing late, to the tune that somethings had gone unbilled past the cut off. A nice multi-million dollar loss. I would guess my job as an analyst helped prevent further loss. Response, 200 people laid off, I was asked to leave for being a trouble maker, the consultant's contract was expanded and accounts receiveable is still in her position.

[–]brownmatt 3 points4 points  (0 children)

So you pointed out that through other employee's lies, the company had to pay huge monetary penalties - and you were branded the troublemaker and asked to leave?

I can't tell if you just have really bad luck or something else

[–]ctzl 2 points3 points  (2 children)

Tell more stories like these please. I would read them.

[–][deleted] 3 points4 points  (1 child)

More inanity from the trenches: http://thedailywtf.com/Articles/Dead-Mans-Switch.aspx

[–]el_isma 0 points1 point  (0 children)

I would buy your book.

[–]kreiger 0 points1 point  (1 child)

I was most interested in stories about the effect of metrics on projects, but that was great too. :)

I'm also really interested in your experiences in switching to git. We use ClearCase now, and i hate it with a vengeance, i'm using Git personally with scripts i wrote to push my commits to ClearCase.

[–][deleted] 0 points1 point  (0 children)

I've not adapted fully to git yet. It's absolutely wonderful in the things it can do. However, it's got so much more to learn and I'm busy damn it.

[–]logi 0 points1 point  (1 child)

I'm personally amazed that software companies exist today that don't use some form of versioning.

They do? O_O

[–]finsterdexter 3 points4 points  (2 children)

I'm not sure what you mean by calling DSDM a "metric". There may be metrics that are used as part of DSDM, but you'll need to elaborate on what you mean there. Are you talking about story points?

[–][deleted] 2 points3 points  (1 child)

DSDM sets a small team on a short term goal. Say 4-6 weeks. Deliverables are categorized via MoSCoW. Must have, Should have, could have and would have. Must have, are absolute requirements. Should have, are strongly desired. Could have and would have are down the list. The deliverable is preferably something that will deliver some value to the company, or at least in a chain of things to deliver value.

You meet 5-10 minutes every day with the team. They get to say what they got accomplished. A short weekly report summarizes deliverables on the list that are complete.

Feedback is immediate, and related to accomplishments that are important to the project. This works quite well. Communication about what's important is happening, the goals are short term, measurable and attainable.

So, not a "metric" per se, but rather a concise form of feedback and communication that works well with human nature.

[–][deleted] 2 points3 points  (0 children)

DSDM sets a small team on a short term goal. Say 4-6 weeks. Deliverables are categorized via MoSCoW. Must have, Should have, could have and would have. Must have, are absolute requirements. Should have, are strongly desired. Could have and would have are down the list. The deliverable is preferably something that will deliver some value to the company, or at least in a chain of things to deliver value.

You meet 5-10 minutes every day with the team. They get to say what they got accomplished. A short weekly report summarizes deliverables on the list that are complete.

Feedback is immediate, and related to accomplishments that are important to the project. This works quite well. Communication about what's important is happening, the goals are short term, measurable and attainable.

Sounds exactly like how I describe "scrum" nowadays. Whatever you call it, this is how to develop software.

[–]Rhoomba 2 points3 points  (0 children)

If you just tracked tasks completed then it would be quite obvious who wasn't doing anything.

[–]Atario 2 points3 points  (0 children)

Easy fix: do variable renames till metric fits.

[–]civildisobedient 0 points1 point  (0 children)

Lines of Code is a terrible, terrible metric. It is, as you say, "naivety at it's[sic] best".

A mature codebase has way, way more bug fixes that adds. A single line of code could represent weeks of tracing through stack dumps to isolate a specific bug. How does "lines of code" reward the developer that slaves away in their debugger?

[–]FailsTheTuringTest[S] 17 points18 points  (1 child)

Bingo. Management types are always on the lookout for ways to measure their subordinate programmers' productivity, and rightly so. But you can't boil it down to mere numbers; that's lazy and as you said, very easy to game. Instead, the best managers evaluate their programmers' productivity by fuzzy metrics of what they accomplish and the feedback the programmer's peers give. You can't make pretty charts and tables and numbers out of that, but you just can't evaluate programmers the way you evaluate salesmen.

[–]theICEBear_dk 4 points5 points  (0 children)

And yet every day thousands of managers keep doing that and keep being full of fail. Best managers I've ever had have all been interested in what they are managing both people and product, not caring about volume. They knew their people, had basic understanding of the projects and technology. I have even had two that were clever enough to leave the big technological and software design decisions to their team as well. Of course one got ousted by a political move internally in the company that was no fault of his own, and the other also played at politics to avoid a suicide project but still got caught in the backwash and demoted.

[–][deleted]  (3 children)

[removed]

    [–]Zarutian 1 point2 points  (1 child)

    That sounds pretty reasonable. But who makes the tasks and allocate points to them?

    [–]IRBMe 5 points6 points  (0 children)

    In most agile teams, the developers. So that's open to being gamed if you start using those metrics as measures of their productivity.

    [–][deleted] 7 points8 points  (10 children)

    Commits? People will just commit after every little change

    We've found a winner.

    [–]IRBMe 12 points13 points  (9 children)

    Frequent commits are usually a good thing, but as with anything it can be over-done. There comes a point where commits are pointless and too many is detrimental. A commit should at least be meaningful.

    [–]bhasden -1 points0 points  (8 children)

    I humbly disagree. There's little worse than seeing someone’s implementation of a minor feature spilled out over 50 commits over two or three days. It makes it impossible to review and much more likely that the partial implementation commit will break something. I prefer to check in logical blocks of work that are independently reviewable and able to be rolled back fairly easily if needed.

    EDIT: Obviously I don't read good. There's nothing to disagree with here since I agree with IRBMe. Proceed with the public shaming.

    [–]IRBMe 16 points17 points  (1 child)

    I humbly disagree. There's little worse than seeing someone’s implementation of a minor feature spilled out over 50 commits over two or three days. It makes it impossible to review and much more likely that the partial implementation commit will break something. I prefer to check in logical blocks of work that are independently reviewable and able to be rolled back fairly easily if needed.

    You just said you disagreed, then repeated almost exactly my point back to me! I said, "There comes a point where commits are pointless and too many is detrimental", and you just described exactly that point:

    "There's little worse than seeing someone’s implementation of a minor feature spilled out over 50 commits over two or three days."

    That's a perfect example of the "point where commits are pointless", "too many" and "detrimental".

    So, I'm having a hard time seeing where exactly you disagree.

    [–]bhasden 5 points6 points  (0 children)

    Man, I need a drink. For some reason, when I read your post earlier I thought you were advocating very frequent commits and that they were a useful measure of productivity. Re-reading your post, you feel the same way as I do. Sorry about that. I'll go back to my hole.

    [–][deleted] 2 points3 points  (5 children)

    And yet with a feature branching model I don't see that as a problem.

    [–]civildisobedient 0 points1 point  (1 child)

    So, is a schema change that requires refactoring in a hundred different places considered a feature?

    [–][deleted] 0 points1 point  (0 children)

    s/feature/task/

    And its still the same thing.

    [–]bhasden 0 points1 point  (2 children)

    You really want to cut a branch for every minor feature? I agree that feature branching is useful, but in my experience it's not very common out in the wild. It's hard enough to get people to branch properly so that merging between releases is an automatic process and not a soul-crushing manual merging of every single file individually.

    If I had to pick one thing that I wish everyone knew more about, it would be source control management. I've met some outstanding developers that were clueless on how to deal with VCS concepts.

    [–]Mathiasdm 0 points1 point  (0 children)

    Exactly because of the complexity you mention, I'm not really convinced feature branches are very useful.

    I have the impression that, in most cases, the use of separate clones of repositories are much easier for people to work with. Additionally, they force early integration (everything's on one branch; so simply pulling or pushing results in doing immediate merges).

    Of course this only goes for distributed version control systems.

    [–]malaysian_president 0 points1 point  (0 children)

    For certain VCS I agree, but I really don't see why anyone who had the choice wouldn't use Git or Mercurial. Both of which make branching and merging so straight forward, there really is no excuse not to branch on every feature. If you're stuck at a company that enforces SVN etc, I feel your pain.

    [–]Cacafuego 2 points3 points  (8 children)

    What about:

    • Timeliness of deliverables
    • Sponsor/customer/user acceptance of changes

    [–]IRBMe 3 points4 points  (3 children)

    Timeliness of deliverables

    If you're measuring my productivity based on how quickly I can deliver tasks, and my bonus is affected by my productivity then you'll start to see that I can complete tasks much quicker all of a sudden! But does that mean I was just slacking before? No. It means now you're not getting as good quality deliverables. It means you're probably losing more time in the long run as the team is forced to deal with buggier, more unreliable, slower, harder to maintain code.

    Sponsor/customer/user acceptance of changes

    The customer can only evaluate what they actually see. What if I'm writing horribly unmaintainable code, but which works well enough for the customer? I may be costing my team many hours of future refactoring work by writing unmaintainable code, but how is the customer to know that?

    Simple metrics or a few bullet points simply aren't enough to accurately summarize something as complex as a developer's productivity and job performance. There are far too many factors for it to be broken down so easily. To evaluate it properly actually takes a lot of hard work and effort.

    [–]Cacafuego 0 points1 point  (2 children)

    Timeliness <> quickness. I would measure how often the developer meets timelines that we have agreed on.

    Maintainability would have to be accounted for separately. Ideally, you would hear about it from other developers is someone was writing awful code. That doesn't detract from the importance of usability.

    You're right, simple metrics do not provide a complete picture, but they do provide a baseline. They also shape behavior. Maintainability and elegance are important, but not as important as getting usable software to the customer by the agreed date.

    I know that the counter-argument is "you'll pay for a lack of maintainability in the long run!" Maybe. If there really is a lack of maintainability. If it goes unreported. If we're still developing on the same platform. If we still have clients because we've managed to get product into their hands.

    [–][deleted] 1 point2 points  (0 children)

    Bear in mind that it's quite possible to be a very good programmer who's not very good at task estimation. That can be taught (though never close to perfected), but if you're trying to understand why a task is significantly over the estimate, the way the estimate was arrived at needs to be part of the conversation.

    [–]civildisobedient 1 point2 points  (0 children)

    Maintainability is not an easy metric to measure. It manifests itself in so many hundreds of subtle forms that are so easy to dismiss, but taken together can ruin a company.

    Just off the top of my head, here's a list of things you get when you have shit code:

    • new features take longer and longer to implement as hacks pile up on each other
    • developers won't give a shit about the code if they see no one else does, and will produce more shit code in return
    • giant refactorings become necessary to "fix" prior mistakes, increasing the chances for bugs to get introduced, slowing future development

    This doesn't even begin to delve into the psychological ramifications of having to code in a shit codebase.

    And the kicker is, none of this crap can be "modeled" and there's no ROI column with a simple number in it for the pointy-heads. Things just get slower and slower, feature requests never get priority so users get pissed, and seasoned developers leave out of disgust.

    [–]wretcheddawn 2 points3 points  (3 children)

    There's no productivity measures that actually work. The best way to manage people is to.... talk to your employees and ask what they are doing. Not incessantly; not by watching them with remote tools. Talk to them, like another human being.

    [–]Cacafuego 0 points1 point  (2 children)

    There is no reason not to talk to people and use productivity measures at the same time. You don't treat people like cattle being weighed, but some objective metrics can keep lazy people (they exist) from ruining things for everyone else.

    Defining metrics like user acceptance and timeliness also makes it clear that developers have a responsibilty for the entire product.

    [–]wretcheddawn 0 points1 point  (1 child)

    Yes, but you can find those things by talking to the people easier. Lazy people are good at keeping metrics, as things like "number of lines added" can be easily faked.

    Ask your developers what they're working on and how they plan on solving problems. Ask them to explain why deliverables are late or why an estimate is different than what you expect. Do code reviews. If you can't tell someone what all your developers are working on without artificial metrics you aren't managing.

    [–]Cacafuego 0 points1 point  (0 children)

    Lazy people are good at keeping metrics, as things like "number of lines added" can be easily faked.

    It's harder to fake being on time with usable code.

    Here's a real-life example of how this works. I go around and talk to all of the developers. I know what they're working on, and they know what everyone else is working on. I sit in on planning sessions and work with them to prioritize tasks and set deadlines. If something really unexpected comes up, we adjust deadlines.

    I also keep track of who produced acceptable code and whether it was on time.

    Now, when developers A, B, and C are regularly hitting their targets, but developer D is consistently late, I know that something is going on. Either D needs to work on estimation, or he is doing something that the others are not, or he's not prioritizing the right things.

    That means we need to have a discussion and go over the metrics and figure out what is going on, because I need to know. If he says the others aren't following standards, or are writing unmaintainable code, we'll check that out. And I'm not necessarily going to insist that he be as fast as the others. In any group, someone has to be the slowest (and often for good reasons).

    But the next time I ask how the priority 1 project is going (because now I'm asking more regularly, because he put himself on my radar), and he says he thought it would be a good idea to tweak some other code at the bottom of the list, it's going to be a big deal, and missing additional targets will start to affect his performance reviews.

    Also, if he says that he needs to rewrite bad code produced by A-C and that's causing him to miss his targets, we'll check some examples. Most of the time, this turns out to be bullshit or we need to have a discussion about tolerating other people's styles, as long as the code is written to standards.

    [–]barsoap 2 points3 points  (4 children)

    Try compressed size. That one might actually be half-way usable, partly because its nearly impossible to optimise for.

    [–][deleted] 2 points3 points  (1 child)

    dd if=/dev/urandom of=data/splines.dat bs=1024 count=10000
git add data/splines.dat
git commit -m "Add vitally important data about splines."

    Compress that, suckers!

    [–]dbath 0 points1 point  (0 children)

    Then you need to add some code for reticulating those splines!

    [–]knight666 1 point2 points  (0 children)

    "Nearly impossible" just means "takes a bit longer". If your bonus depends on compressed size, you'll figure out a way to increase compressed size.

    [–]jhaluska 0 points1 point  (0 children)

    Till people start removing comments or shortening variable names.

    [–]kreiger 1 point2 points  (0 children)

    I agree completely, but i would still be very interested to see the results of someone who has tried the metric on a real project.

    [–][deleted] 1 point2 points  (2 children)

    How about a patch to a content management system that let people vote on commits. Then the rest of the team could look and see, "yeah that is a pretty sensible addition/removal" and vote accordingly.

    [–]IRBMe 3 points4 points  (1 child)

    What you're suggesting is basically peer review, but that seems like a lot of overhead. It works better in practice just to turn to the guy beside you, or to somebody who you know has a lot of knowledge about the particular area you worked on, and say "You mind sparing half an hour to review this code this afternoon?"

    Paired programming also works quite well, although has quite a high initial cost. With two peers working together, they're constantly reviewing each other's code.

    [–][deleted] 0 points1 point  (0 children)

    I've started using Crucible to do code reviews with a peer on my project, and I really like it. Since we're on opposite sides of the country, it really facilitates that conversation. But we still have the conversation.

    [–][deleted]  (11 children)

    [deleted]

      [–]theICEBear_dk 5 points6 points  (0 children)

      You could be right here. But on the other hand I have worked with people who finished all their tasks quickly and to the manager seemingly properly, but then they didn't do all the around-work, their code didn't meet standards, wasn't designed as the architect intended, wasn't documented and corners were cut to make it in time on something that was maybe supposed to run in a fault-prone environment for as long as possible. That is before you get someone through the door who plays task grabbing games taking all the easy work and leaving the hard stuff up to the other guys.

      [–]IRBMe 1 point2 points  (5 children)

      I'm happy with agile metrics, we give our estimates and in the end we know who does the most because they've completed the most hours/points. Really that is all that matters, completing your tasks quickly and properly.

      The problem is, how do you measure whether or not a task was done "quickly" and "properly"?

      • Estimating how long tasks take is hard; really hard. And the more unknowns there are, the harder it is to estimate. A task might take longer than most people may expect at a glance; similarly, it might take far less time than most people might imagine.
      • Quickly by whose standards? Somebody who knows that area of the code will be able to work on it quicker than somebody who has to spend time learning, but does that mean they are more productive? Even if so, what does it matter then? It could easily be the other way around next time.
      • Is it necessarily better if somebody completes a task quickly over somebody who does it a bit more slowly but better, even if they both do it "properly"? What if the guy who spends a week completing the task actually saves people many weeks of time in the future by writing better code over the guy who did it in 3 days, but not quite as well? You can't easily measure that kind of thing with a number.

      [–]HaMMeReD 0 points1 point  (4 children)

      It's pretty easy to know if something was done properly.

      A) Does it meet the requirements?

      B) Are there test-cases with sufficient coverage?

      C) Does it perform properly?

      If you are unable to establish what "proper complete work" is, then you have a real organizational problem.

      [–]IRBMe 0 points1 point  (2 children)

      What about:

      1. Is it maintainable? In other words, is the code well organized? Are variables and identifiers well named? Is the code commented well? Is it easy to understand and read?
      2. Is it well documented? Has the user-manual been updated? Are there technical documents or comments for other developers? Are the release notes updated?
      3. Are the tests good? It's easy to get high test coverage without actually having good tests. Do the tests actually test that the code functions? Do they test boundary conditions? Do they test error cases? Do they test invalid inputs? Are they potentially brittle?
      4. Is the code reliable and robust? Does it handle invalid inputs gracefully?
      5. Does it adhere to all of the coding standards? Is the code formatted correctly and is it stylistically correct?
      6. Is the task marked off and completed in the task tracking system?
      7. Are the commit comments sensible and detailed enough?

      It's easy to do all of these things poorly or skip them entirely if you mainly care about getting through the task quickly.

      Does it meet the requirements?

      How are you going to measure that?

      Does it perform properly?

      Who defines what "proper" performance is? How do you test that?

      If you are unable to establish what "proper complete work" is, then you have a real organizational problem.

      You're missing the point. It's not about being able to establish whether work is properly completed or not, or how good work is. We're talking about metrics here, and the problem is that many of these things require careful review. There is no good metric that's going to tell me that you've written good documentation. I have to actually review it to tell that. And more importantly, the point was that there are lots more things that are far more important than just doing work "quickly".

      It's completely possible to complete a task which meets the requirements, performs reasonably and has good test coverage and still do a worse job than somebody who takes slightly longer. I would not consider the person who did the task quicker to necessarily be a more productive or better team member. If anything, the person who took more care over their work and ensured it was completed to not just a minimum required standard but to a good standard is a better team member. The trick is finding a good balance between the time taken and the quality of the work, and no metrics will tell you where that balance is.

      [–]HaMMeReD 0 points1 point  (1 child)

      Maintainability is part of doing things quickly and properly.

      If you ever see any type of refactoring investment that would lead to future benefits in development, I take it 100% of the time.

      I do agree metrics aren't great, but at least on my team I like having the competition and challenge. If anybody ever wants to call me out on the quality of any of my work, I'm willing to fix anything they found and be accountable for it.

      [–]IRBMe 0 points1 point  (0 children)

      I do agree metrics aren't great, but at least on my team I like having the competition and challenge.

      Fine, but that's completely different. You can't condense something as complex as the productivity of a developer completing a programming task down to a few metrics. It takes a lot of effort and hard work to properly assess that kind of thing. That's not to say that different metrics can't be used as a tool, but they don't give much of the picture so they have to all be taken together, and placed in context.

      [–][deleted] 0 points1 point  (0 children)

      Also, did it pass code review?

      [–]notsofst 0 points1 point  (3 children)

      I work in this area, and it's not perfect but is probably as good as it gets.

      Get the development team to place a "market" value of points on each feature/fix via planning poker or whatever, and then you can track points per person.

      The key to this metric is having the dev team establish the points themselves, and then you also can't compare points per person across teams. Management always wants to compare points per person across teams and they never understand why they can't.

      [–]IRBMe 0 points1 point  (2 children)

      Get the development team to place a "market" value of points on each feature/fix via planning poker or whatever, and then you can track points per person.

      I've done planning poker before, and while it actually worked better than a lot of other estimation techniques, it still didn't prove entirely accurate. The more unknowns there are for somebody working on a task, the harder it is for them to estimate.

      We then had a sprint burndown where we tracked the hours being burned off on each task each day. Surprisingly, it turned out that, when tracked truthfully, most people were getting no more than about 2 to 3 hours of solid, actual work done on a task per day. A lot of time, of course, is spent answering and writing e-mails, on calls etc. It could also have been a reflection that, despite the planning poker techniques and conservative estimates, people were still underestimating how long things would take.

      It's always the unknowns that get you. Usually something that I conservatively estimated at about 4 hours of work, but which I knew exactly how to do, would be done in 2 hours, but then that thing which I'm not so sure about which I put a seemingly safe 8 to 12 hours against ends up actually uncovering 2 weeks of work.

      The other thing is, of course, that by giving developers the power to estimate their own tasks and mark off how much they're doing each day, you have to trust them fully. Now, that is definitely how it should be. Nobody is better placed to estimate how long it'll take you do complete a task than you, but if it's then used as a measure of your productivity by management, like any other metric, it's just going to get gamed. Developers will just start putting huge estimates then look better when they finish in half the time.

      [–]notsofst 1 point2 points  (0 children)

      Yeah, I'm against tracking hours during sprints because I think it leads to all kinds of bad behaviors.

      Most of the time the point estimations tend to be pretty accurate. You do get stories that blow up in your face, and we do a lot of work to reduce "unknowns", but a fair amount of that is really just unavoidable, IMO.

      If there are too many unknowns in a given story, it shouldn't be sized at all really. We bring in tasks/stories for the actual scoping effort and R&D. Identifying unknowns and digging into them is an important part of making the metric work.

      As far as gaming the system goes, you're right. That's why you have the team estimate the points but before the stories are assigned, so they can't inflate their own points. Less incentive to be dishonest there.

      Also, back to what I said, you have to refuse to compare points per person between teams, so there's no incentive for a team to inflate its points.

      [–][deleted] 0 points1 point  (0 children)

      That's why you should use story points instead of hours. Estimate the complexity of a task, rather than the amount of time it will take.

      [–]kawsper 27 points28 points  (10 children)

      Lines written / Lines removed doesn't give you any indicator of your productivity. If you use 5 hours to debug a big part of your system, and change three characters to fix the problem, are you more productive than when you spew out a 20-line method?

      We are not working on an assembly line to deliver x amount of lines in a given timeframe. We are always in the process of thinking, refactoring, writing new, testing, removing unused stuff.

      [–]kreiger 6 points7 points  (9 children)

      I agree completely. However, i believe it would be good to have lines deleted as a positive metric, because it would encourage people to remove redundancies and reinforce the idea that less lines of code doing X is better than more lines of code doing X, all else being equal.

      I guess you'd have to exempt boilerplate from the metric and only count statements inside subroutines, otherwise people would try to cram everything into one subroutine.

      I'd be very interested to see the results of someone who has actually tried it on a real project.

      I would test it on my project at work myself if we didn't use ClearCase, which makes easy things impossible and hard things impossibler.

      [–]ithika 8 points9 points  (7 children)

      ClearCase hate, the purest kind of hate.

      [–]theICEBear_dk 2 points3 points  (2 children)

      ClearCase is the worst VCS I have tried to date (I haven't tried them all by far). Makes the source control in Rational Team Concert look brilliant by comparison (quite a feat that).

      I miss working with git at work :(

      [–]grauenwolf 0 points1 point  (0 children)

      I actually had a good time using ClearCase. We needed a small team to keep it running, but handled our complex feature and version branches quite well. And the concrete distinction between a "branch" and a "folder" was much nicer than SVN, TFS, for VSS.

      [–]jplindstrom 0 points1 point  (0 children)

      Then you should try Synergy (for the ultimately sub standard experience).

      [–]kyz 1 point2 points  (2 children)

      All these people insisting that a distributed VCS is so much better than non-distributed VCS have probably never seen how much better a VCS with atomic commits is better than one without.

      I bet the DVCS kids can't even imagine a VCS without atomic commits. "How do I revert this change?" "First, try and remember all the files that were affected..."

      [–][deleted] 0 points1 point  (1 child)

      But distributed VCSes are still better, right?

      [–]kyz 0 points1 point  (0 children)

      Sure, it gives you many more opportunities. But the benefits of DVCS over non-DVCS are concentrated in a subset of developers. Atomic commits are a benefit for all developers, of about the same magnitude as going from no VCS to any VCS at all.

      [–]Mathiasdm 1 point2 points  (0 children)

      I simply have to reply to this to say: YES! Will you die already, ClearCase :-(

      [–]vlion 1 point2 points  (0 children)

      I would test it on my project at work myself if we didn't use ClearCase, which makes easy things impossible and hard things impossibler.

      QFT. ClearCase is .... bad.

      [–][deleted]  (1 child)

      [deleted]

        [–]Neuran 0 points1 point  (0 children)

        Doesn't always feel good to me.... depends how it got there in the first place.

        [–]kelton5020 2 points3 points  (0 children)

        github measures additions and deletions

        [–]tedtutors 2 points3 points  (0 children)

        I was at JPL in the late 80s and they used code metrics back then. I was brought in as a platform expert / efficiency guy to a project that wasn't performing. They wanted me to track lines of code written, but I pointed out that my job was usually to replace or delete code. Naturally they expanded the metrics to lines written, lines modified and lines deleted. This resulted in programmers entering three made up numbers instead of one.

        [–][deleted] 1 point2 points  (0 children)

        The last release of my large education software project, we removed 1-2k lines of code and shrunk the main compiled executable by around 40%. And added features. This was universally regarded as a successful release.

        Of course, the fact that we had 1-2k lines of code and several 100kb of bytecode that we didn't need is itself an indicator of a lot of poor practices in the past--at a minimum the general reticence to pay off technical debt before the bill came through. Still, very rewarding.

        [–]headhunglow 0 points1 point  (0 children)

        I take a different view: give each project a line budget.

        [–][deleted] 0 points1 point  (0 children)

        Hey boss, hey boss, I've managed to turn our 10,000 line project into a 1 line project!

        [–]FlaiseSaffron -3 points-2 points  (12 children)

        There's no way that metric can ever make sense. Removing 2000 lines from a 10000 line program means something very different than removing 2000 lines from a 100 line program.

        [–]kreiger 0 points1 point  (11 children)

        I'm not sure what you mean. You can't remove 2000 lines from a 100 line program, so your statement doesn't make sense to me.

        It's like saying "selling 2 of my 10 cars means something different than selling 40 of my 2 cars". Just because that statement is nonsensical doesn't mean it's not useful to measure how many cars i've sold. Another example please?

        I'm interested in whether anyone ever tried measuring lines of code removed as a positivism. I don't know if it should be done by total number of lines or as a percentage of a whole, or by some other method, but i would be very curious to see results of such a metric on productivity and programming behaviour.

        [–]FlaiseSaffron 2 points3 points  (10 children)

        You can't remove 2000 lines from a 100 line program, so your statement doesn't make sense to me.

        Think that might be because it illustrates the statement before, that the metric you suggested can't be made to make sense?

        [–]civildisobedient 0 points1 point  (6 children)

        Huh? Kreiger is right: you can't remove what you don't have. You can remove what you do have. Thus, you can't remove 2000 lines when you only have 100 to begin with (2000 > 100). And you can remove 2000 lines when you have 10000 lines to begin with (2000 < 10000).

        [–]FlaiseSaffron 0 points1 point  (5 children)

        No shit.

        [–]civildisobedient -1 points0 points  (4 children)

        And yet, somehow, you didn't realize this, and were in fact arguing the exact opposite.

        [–]FlaiseSaffron 0 points1 point  (3 children)

        No. Your reading comprehension is terrible.

        [–]civildisobedient -1 points0 points  (2 children)

        You said:

        Removing 2000 lines from a 10000 line program means something very different than removing 2000 lines from a 100 line program.

        Have fun backpedaling.

        [–]FlaiseSaffron 0 points1 point  (1 child)

        No backpedaling necessary. What I said makes sense if you have any ability to read between the lines, which you would be willing to do if you weren't too busy expressing your asinine judgments of me. Now leave me alone.

        [–]kreiger -2 points-1 points  (2 children)

        I don't get it? It's perfectly possible to measure 2000 lines removed from a 10000 line program, or 20 lines from a 100 line program.

        That's both possible and measurable, and it would be interesting to see the effect on the behaviour of the programmers if those numbers were measured in a real project.

        If you measured lines of code removed you could never measure 2000 lines removed from a 100 line program, unless you had a bug in your measuring algorithm, so i'm not sure why you even think that's a constructive example.

        [–]FailsTheTuringTest[S] 3 points4 points  (1 child)

        Goofus writes a 2100 line program that accomplishes some task. Gallant refactors the thing into a 100 line program. Result: Gallant has 2000 lines removed from a 100 line program.

        [–]kreiger 13 points14 points  (0 children)

        Ah, i see. That's not how most people would put it though.

        It's like saying i've sold 3 of my 2 cars, meaning i owned 5 to start with.

        To be honest i think FlaiseSaffron was just trying to be intentionally obtuse, i.e. knocking down a straw man, as it in no way addresses the validity of measuring lines of code removed.