Loading ...
Sorry, an error occurred while loading the content.
 

Re: [XP] Re: Kate Oneal on Productivity

Expand Messages
  • John A. De Goes
    ... I don t know better. I did suggest another one: code duplication. ... Sorry, I should have added: unroll loops and eliminate conditionals (this is usually
    Message 1 of 192 , Mar 1, 2008
      On Mar 1, 2008, at 10:09 AM, Ron Jeffries wrote:
      > Yes, they are indicators. If you know better ones, I'd like to know
      > them.
      >

      I don't know better. I did suggest another one: code duplication.

      > The cyclomatic complexity of this program will be way more than
      > zero. Cyclomatic complexity counts if statements and loops //and the
      > number of /different/ paths through them.//
      >

      Sorry, I should have added: unroll loops and eliminate conditionals
      (this is usually possible by performing both paths). This will
      increase the size of the program tremendously, and also the amount of
      duplication in it.

      > > Semantic Designs has some tools for detecting similar fragments of
      > > code, which could be another useful indicator of technical debt. But
      > > there are problems: first, many programs can be simplified by first
      > > rewriting code so that duplications emerge (generalizing), and then
      > > factoring out the resultant duplication. Second, many kinds of
      > > duplication are orthogonal to the syntax of the language. They can't
      > > be factored out given the constraints of the grammar of the language
      > > (although aspect-oriented programming can factor some of them out).
      >
      > Yes ... and your point would be what?
      >

      I'm arguing that the additional indicator I mentioned, code
      duplication, has severe limitations of its own.

      > I can't accurately measure much of anything. But I can know a lot.
      > If we know we are far away from where we want to be, and we can
      > recognize what's better, why isn't that enough?
      >

      It's good, but remember the context of this discussion: the metric
      proposed by Marty.

      viz.: productivity = stories / (technical debt + defects)

      If you can't even hope to accurately measure technical debt (and I
      would add, other forms of debt such as psychological debt), not to
      mention defects, then the value of such a metric is limited (maybe
      zero).

      I'm not arguing that indicators are useless, which is what you seem to
      think I'm arguing for.

      Regards,

      John A. De Goes
      N-BRAIN, Inc.
      http://www.n-brain.net
      [n minds are better than n-1]
    • Ron Jeffries
      ... I freely grant that having someone come in and point to issues in the code is helpful. But I ve never seen a team where none of them knew they were
      Message 192 of 192 , Mar 10, 2008
        Hello, Steven. On Friday, March 7, 2008, at 8:23:05 PM, you wrote:

        >> Why do you say this? Every team I've ever had anything to do with
        >> knew when it was producing crap.

        > Ron,

        > Before you had associated with them, or only after you had
        > enlightened them?

        I freely grant that having someone come in and point to issues in
        the code is helpful. But I've never seen a team where none of them
        knew they were producing junk. Of course, I only see teams who are
        at least somewhat aware that they need help.

        > I have encountered quite a few teams this century who were quite
        > openly proud of their cleverly engineered proprietary DAO, not
        > understanding that they had in reality wasted several person-months
        > creating something inferior to freely available frameworks like
        > Hibernate and whose maintenance was going to degrade their velocity
        > until they finally gave up their pride and replaced it with
        > (N)Hibernate (or the equivalent).

        > Seriously, you have not encountered this phenomenon?

        You describe a phenomenon illustrating my point, where a team
        realizes that their home-grown DAO is holding them back. Yes. It's
        an example of teams figuring out that they are producing / have
        produced crap.

        And my guess is that some of them knew long before, and quite
        possibly even said so. If a team is any good at all, at least some
        of them know.

        Ron Jeffries
        www.XProgramming.com
        If you don't have the courage to say what you think,
        there isn't much use in thinking it, is there?
        --Thomas Jay Peckish II
      Your message has been successfully submitted and would be delivered to recipients shortly.