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

Re: LOC - was Re: [XP] Software Architecture start f rom….//...?

Expand Messages
  • Bill Caputo
    ... Right, LOC is a counter-performance measure (i.e. a rough estimate of how much your maintenance burden is) not something to be proud of for its own sake.
    Message 1 of 8 , Jun 9, 2010
      On Wed, Jun 9, 2010 at 8:22 AM, Tim Ottinger <linux_tim@...> wrote:
      > Don't ignore LOC.  It is an indicator of how bloated your software is.

      Right, LOC is a counter-performance measure (i.e. a rough estimate of
      how much your maintenance burden is) not something to be proud of for
      its own sake.

      (tongue in cheek): So, programmer compensation should be based on
      reducing LOC not increasing it (can already see the dlibert where
      wally sits in a cube doing nothing and scores a fat bonus).

      Bill

      > If you lower LOC by eliminating duplication or introducing abstractions,
      > then it is a good thing.  If you lower it by cramming more crap on each
      > line, it is a horrid mistake. It's not a great indicator, but we so love
      > those "increased function while decreasing linecount" days.
      >
      >
      >  Tim Ottinger
      > http://agileinaflash.blogspot.com/
      > http://agileotter.blogspot.com/
      >
      >
      >
      >
      >
      >
      > ------------------------------------
      >
      > To Post a message, send it to:   extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.comYahoo! Groups Links
      >
      >
      >
      >
    • James Carr
      Sometimes it amazes me that some teams can sit down and just crank out a MILLION lines of code to write an application pretty trivial. I ve come to understand
      Message 2 of 8 , Jun 9, 2010
        Sometimes it amazes me that some teams can sit down and just crank out a
        MILLION lines of code to write an application pretty trivial. I've come to
        understand the forces that cause it to happen, but it still amazes me to see
        codebases that huge that were written over a short period of time. I mean,
        it still boggles my mind that some people can not only justify it, but also
        be proud of the LOC they personally generated.


        Thanks,
        James

        On Wed, Jun 9, 2010 at 8:26 AM, Bill Caputo <
        list-subscriber@...> wrote:

        >
        >
        > On Wed, Jun 9, 2010 at 8:22 AM, Tim Ottinger <linux_tim@...<linux_tim%40yahoo.com>>
        > wrote:
        > > Don't ignore LOC. It is an indicator of how bloated your software is.
        >
        > Right, LOC is a counter-performance measure (i.e. a rough estimate of
        > how much your maintenance burden is) not something to be proud of for
        > its own sake.
        >
        > (tongue in cheek): So, programmer compensation should be based on
        > reducing LOC not increasing it (can already see the dlibert where
        > wally sits in a cube doing nothing and scores a fat bonus).
        >
        > Bill
        >
        >
        > > If you lower LOC by eliminating duplication or introducing abstractions,
        > > then it is a good thing. If you lower it by cramming more crap on each
        > > line, it is a horrid mistake. It's not a great indicator, but we so love
        > > those "increased function while decreasing linecount" days.
        > >
        > >
        > > Tim Ottinger
        > > http://agileinaflash.blogspot.com/
        > > http://agileotter.blogspot.com/
        > >
        > >
        > >
        > >
        > >
        > >
        > > ------------------------------------
        >
        > >
        > > To Post a message, send it to: extremeprogramming@...<extremeprogramming%40eGroups.com>
        > >
        > > To Unsubscribe, send a blank message to:
        > extremeprogramming-unsubscribe@...<extremeprogramming-unsubscribe%40eGroups.com>
        > >
        > > ad-free courtesy of objectmentor.comYahoo! Groups Links
        > >
        > >
        > >
        > >
        >
        >
        >


        [Non-text portions of this message have been removed]
      • M. Manca
        Il 09/06/2010 15.42, James Carr ha scritto: In my opinion LOCs are an old simple source code size measure that can t be directly used to make an estimation
        Message 3 of 8 , Jun 9, 2010
          Il 09/06/2010 15.42, James Carr ha scritto:
          In my opinion LOCs are an old simple source code size measure that can't
          be directly used to make an estimation about effort, costs and
          development time but for existing applications could help to give an
          approximated idea about how big is one module or about the quantity of
          lines to modify/add to modify the application. So I would say that LOCs
          may be a sort of post-mortem data to verify/compare or using partially
          as a collection of examples for the next application. A good thing could
          be to have some sort of automated application taking care about the time
          spent to realize every piece (function? class?) of source code giving
          the possibility to establish an historical database helpul to estimate
          new applications.
          > Sometimes it amazes me that some teams can sit down and just crank out a
          > MILLION lines of code to write an application pretty trivial. I've come to
          > understand the forces that cause it to happen, but it still amazes me to see
          > codebases that huge that were written over a short period of time. I mean,
          > it still boggles my mind that some people can not only justify it, but also
          > be proud of the LOC they personally generated.
          >
          >
          > Thanks,
          > James
          >
          > On Wed, Jun 9, 2010 at 8:26 AM, Bill Caputo <
          > list-subscriber@...> wrote:
          >
          >
          >>
          >> On Wed, Jun 9, 2010 at 8:22 AM, Tim Ottinger <linux_tim@...<linux_tim%40yahoo.com>>
          >> wrote:
          >>
          >>> Don't ignore LOC. It is an indicator of how bloated your software is.
          >>>
          >> Right, LOC is a counter-performance measure (i.e. a rough estimate of
          >> how much your maintenance burden is) not something to be proud of for
          >> its own sake.
          >>
          >> (tongue in cheek): So, programmer compensation should be based on
          >> reducing LOC not increasing it (can already see the dlibert where
          >> wally sits in a cube doing nothing and scores a fat bonus).
          >>
          >> Bill
          >>
          >>
          >>
          >>> If you lower LOC by eliminating duplication or introducing abstractions,
          >>> then it is a good thing. If you lower it by cramming more crap on each
          >>> line, it is a horrid mistake. It's not a great indicator, but we so love
          >>> those "increased function while decreasing linecount" days.
          >>>
          >>>
          >>> Tim Ottinger
          >>> http://agileinaflash.blogspot.com/
          >>> http://agileotter.blogspot.com/
          >>>
          >>>
          >>>
          >>>
          >>>
          >>>
          >>> ------------------------------------
          >>>
          >>
          >>> To Post a message, send it to: extremeprogramming@...<extremeprogramming%40eGroups.com>
          >>>
          >>> To Unsubscribe, send a blank message to:
          >>>
          >> extremeprogramming-unsubscribe@...<extremeprogramming-unsubscribe%40eGroups.com>
          >>
          >>> ad-free courtesy of objectmentor.comYahoo! Groups Links
          >>>
          >>>
          >>>
          >>>
          >>>
          >>
          >>
          >>
          >
          > [Non-text portions of this message have been removed]
          >
          >
          >
          > ------------------------------------
          >
          > To Post a message, send it to: extremeprogramming@...
          >
          > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
          >
          > ad-free courtesy of objectmentor.comYahoo! Groups Links
          >
          >
          >
          >
          >
          >



          [Non-text portions of this message have been removed]
        • John Goodsen
          ... so if programmers should get paid by reducing the LOC, I just might go back and do some Java for the cash. Armed with IntelliJ, I can target Java code,
          Message 4 of 8 , Jun 10, 2010
            ... so if programmers should get paid by reducing the LOC, I just might go
            back and do some Java for the cash. Armed with IntelliJ, I can target Java
            code, convert it to Scala and significantly reduce the LOC count. Be
            careful what you measure - you'll be sure to get it.


            On Wed, Jun 9, 2010 at 10:20 AM, M. Manca <m.manca@...>wrote:

            > Il 09/06/2010 15.42, James Carr ha scritto:
            > In my opinion LOCs are an old simple source code size measure that can't
            > be directly used to make an estimation about effort, costs and
            > development time but for existing applications could help to give an
            > approximated idea about how big is one module or about the quantity of
            > lines to modify/add to modify the application. So I would say that LOCs
            > may be a sort of post-mortem data to verify/compare or using partially
            > as a collection of examples for the next application. A good thing could
            > be to have some sort of automated application taking care about the time
            > spent to realize every piece (function? class?) of source code giving
            > the possibility to establish an historical database helpul to estimate
            > new applications.
            > > Sometimes it amazes me that some teams can sit down and just crank out a
            > > MILLION lines of code to write an application pretty trivial. I've come
            > to
            > > understand the forces that cause it to happen, but it still amazes me to
            > see
            > > codebases that huge that were written over a short period of time. I
            > mean,
            > > it still boggles my mind that some people can not only justify it, but
            > also
            > > be proud of the LOC they personally generated.
            > >
            > >
            > > Thanks,
            > > James
            > >
            > > On Wed, Jun 9, 2010 at 8:26 AM, Bill Caputo <
            > > list-subscriber@...> wrote:
            > >
            > >
            > >>
            > >> On Wed, Jun 9, 2010 at 8:22 AM, Tim Ottinger <linux_tim@...
            > <linux_tim%40yahoo.com>>
            > >> wrote:
            > >>
            > >>> Don't ignore LOC. It is an indicator of how bloated your software is.
            > >>>
            > >> Right, LOC is a counter-performance measure (i.e. a rough estimate of
            > >> how much your maintenance burden is) not something to be proud of for
            > >> its own sake.
            > >>
            > >> (tongue in cheek): So, programmer compensation should be based on
            > >> reducing LOC not increasing it (can already see the dlibert where
            > >> wally sits in a cube doing nothing and scores a fat bonus).
            > >>
            > >> Bill
            > >>
            > >>
            > >>
            > >>> If you lower LOC by eliminating duplication or introducing
            > abstractions,
            > >>> then it is a good thing. If you lower it by cramming more crap on each
            > >>> line, it is a horrid mistake. It's not a great indicator, but we so
            > love
            > >>> those "increased function while decreasing linecount" days.
            > >>>
            > >>>
            > >>> Tim Ottinger
            > >>> http://agileinaflash.blogspot.com/
            > >>> http://agileotter.blogspot.com/
            > >>>
            > >>>
            > >>>
            > >>>
            > >>>
            > >>>
            > >>> ------------------------------------
            > >>>
            > >>
            > >>> To Post a message, send it to: extremeprogramming@...
            > <extremeprogramming%40eGroups.com>
            > >>>
            > >>> To Unsubscribe, send a blank message to:
            > >>>
            > >> extremeprogramming-unsubscribe@...
            > <extremeprogramming-unsubscribe%40eGroups.com>
            > >>
            > >>> ad-free courtesy of objectmentor.comYahoo! Groups Links
            > >>>
            > >>>
            > >>>
            > >>>
            > >>>
            > >>
            > >>
            > >>
            > >
            > > [Non-text portions of this message have been removed]
            > >
            > >
            > >
            > > ------------------------------------
            > >
            > > To Post a message, send it to: extremeprogramming@...
            > >
            > > To Unsubscribe, send a blank message to:
            > extremeprogramming-unsubscribe@...
            > >
            > > ad-free courtesy of objectmentor.comYahoo! Groups Links
            > >
            > >
            > >
            > >
            > >
            > >
            >
            >
            >
            > [Non-text portions of this message have been removed]
            >
            >
            >
            > ------------------------------------
            >
            > To Post a message, send it to: extremeprogramming@...
            >
            > To Unsubscribe, send a blank message to:
            > extremeprogramming-unsubscribe@...
            >
            > ad-free courtesy of objectmentor.comYahoo! Groups Links
            >
            >
            >
            >


            --
            John Goodsen RADSoft / Better Software Faster
            jgoodsen@... Lean/Agile/XP/Scrum Coaching and Training
            http://www.radsoft.com Ruby on Rails and Java Solutions


            [Non-text portions of this message have been removed]
          Your message has been successfully submitted and would be delivered to recipients shortly.