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

Counting Lines Considered Harmful [Was: XP and .NET popularity]

Expand Messages
  • Phlip
    ... Here s the summary. Those who may feel like arguing should look up the threads I m summarizing first: You get what you measure. High line count is bad;
    Message 1 of 219 , Jan 1, 2003
    • 0 Attachment
      Kathleen Dollard sez:

      > > > What happens to XP in a 400 KLOC - 1,000 KLOC project?
      > >
      > > Nothing. You shouldn't notice the line count, wherever it goes.

      > Interesting

      Here's the summary. Those who may feel like arguing should look up the
      threads I'm summarizing first:

      You get what you measure.

      High line count is bad; it's not a sign of progress.

      To avoid getting it, don't measure it at all. Not even for old-time's sake.
      Put a Jedi Mind Trick on it. You don't want to sell me any Death Sticks. You
      want to go home and think about your life.

      _Do_ measure your velocity, and develop a nose for any kind of code
      duplication. Seek and destroy it.

      The best thing to measure may be the time between when the Customer Team
      declares the details for a requirement and the time the end-users start
      adding value using that feature. This is the same as the manufacturing
      concept "high shelf inventory counts are bad".

      http://www.xpsd.com/SoftwareInProcess

      --
      Phlip
      http://www.greencheese.org/SkeletonCrew
      -- "Probably one of the toughest times in anyone's life is when
      you have to kill someone you love because they'r the Devil"
      --Emo Phillips --
    • Daniel Sheppard
      ... If the language isn t doing type-checking on you, you wouldn t have had to refactor that test to make it compile. You would have run your tests and see
      Message 219 of 219 , Jan 5, 2003
      • 0 Attachment
        > > Well, you had a test that did "new Car(owner)" and asserted
        > that this object
        > > returned what you expected from toString() before you
        > refactored. So you break
        > > your unit test.
        >
        > Yes, that test is in the unit tests for Car. When refactoring
        > Car, I of
        > course changed that one to take an OwnerList, rather than an
        > owner. The
        > problem is with someone who *calls* that method. I'm supposing that I
        > forgot about refactoring DmvImporter as well.

        If the language isn't doing type-checking on you, you wouldn't have had to refactor that test to make it compile.

        You would have run your tests and see that it fails, and your first thought at that point should not be "how do I change the test to make it work?" but "how do I change the code to make it work?". This would have led you to change your toString() method operates correctly regardless of it being an owner or an ownerlist. If you don't have control of all the calling code, or you can't trust yourself to change it all, this is the only solution you should be entertaining.

        Daniel Sheppard

        daniels at pronto.com.au
        #####################################################################################
        This email has been scanned by MailMarshal, an email content filter.
        #####################################################################################
      Your message has been successfully submitted and would be delivered to recipients shortly.