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

Re: [XP] Re: Kate Oneal on Productivity

Expand Messages
  • John A. De Goes
    ... To play the part of the pressured developer judged by the productivity metric introduced by Marty: Which will be much later than my status report on
    Message 1 of 192 , Mar 1 8:52 AM
      On Feb 27, 2008, at 11:21 AM, Ron Jeffries wrote:
      > > Defects and debt require effort to discover. Thus as a developer, I
      > > can increase my 'productivity' by finding fewer defects and
      > > discovering less technical debt. Plus I'll have more time for
      > creating
      > > stories, so I'll come out even further ahead!
      >
      > Not when the bug reports come in.
      >

      To play the part of the pressured developer judged by the productivity
      metric introduced by Marty:

      "Which will be much later than my status report on Friday."

      > Field bug reports, mapped back to module and date.
      > Cyclomatic complexity.
      > Test coverage.
      >

      These are indicators of technical debt. But they don't come close to
      measuring it.

      Take a monstrously huge program, and inline every method. Then inline
      every class. Then inline every file. In the end, you'll have a single
      file with lots of statements. Cyclomatic complexity of zero. And
      technical debt too large to measure.

      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).

      In my mind, technical debt is divergence of the system away from a
      theoretical implementation of the system which has no defects and has
      minimal cost to change. Because you don't have that implementation,
      and don't know what it looks like (or else you would simply write
      it!), you can't accurately measure technical debt. At best, you can
      say, "We know we're far away from that system because we have high
      cyclomatic complexity, low test coverage, high duplication, many bugs,
      etc."

      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 6:36 AM
        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.