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

Re: Code Complete: Things were Scary Back Then

Expand Messages
  • dhemeryy
    Hi Brian, ... McConnell s book was a vision of Utopia for most of us. Dale -- But you try to tell that to kids these days, and they won t believe you.
    Message 1 of 8 , Mar 29, 2002
    • 0 Attachment
      Hi Brian,

      > And that's only the first third or so fo the book. Were things
      > really that bad back in the day?

      McConnell's book was a vision of Utopia for most of us.

      Dale

      -- "But you try to tell that to kids these days, and they won't
      believe you."
    • Dossy
      ... Worse. And that s _really_ scary. The bright side is that this is clear evidence that we ARE learning from our mistakes, and that some day in the
      Message 2 of 8 , Mar 29, 2002
      • 0 Attachment
        On 2002.03.29, Brian Christopher Robinson <brian@...> wrote:
        >
        > And that's only the first third or so fo the book. Were things really that
        > bad back in the day?

        Worse. And that's _really_ scary.

        The bright side is that this is clear evidence that we ARE learning
        from our mistakes, and that some day in the (hopefully near, but
        most likely distant) future, things will be a whole lot better.

        -- Dossy

        --
        Dossy Shiobara mail: dossy@...
        Panoptic Computer Network web: http://www.panoptic.com/
        "He realized the fastest way to change is to laugh at your own
        folly -- then you can let go and quickly move on." (p. 70)
      • Brian Christopher Robinson
        As a result of BookPool s 45% off Microsoft Press books this month I picked up Code Complete along with a few others books. I ve read about 150 pages of it so
        Message 3 of 8 , Mar 29, 2002
        • 0 Attachment
          As a result of BookPool's 45% off Microsoft Press books this month I picked
          up Code Complete along with a few others books. I've read about 150 pages
          of it so far and it is very scary. I am quite glad I got my CS degree in
          2000 and my first job after graduating began with an XP project rather than
          starting my career in 93 when this book was published..

          Things that scared me:

          o A whole chapter devoted to convincing people that they should use
          "modules", equivalent to today's object. What's scary is that they would
          need convincing.
          o Saying that global variables shouldn't be used too often. How about not
          at all?
          o A dead serious declaration that methods of 200 lines and longer are
          easier to understand and more bug free than shorter ones.
          o An example where McConnell admits to writing the line "node = node.next"
          everywhere in his program instead of having a method to encapsulate this
          behavior of his linked list.
          o The standard BDUF stuff, although this is to be expected.

          And that's only the first third or so fo the book. Were things really that
          bad back in the day?


          --
          "The best programmers that I have ever met have an amazing ability to make
          nasty sh*t disappear. *Poof*" Gareth Reeves -- reevesg@...
        • jmead1us
          ... about not ... Bah humbug! Next you ll be saying we should avoid GOTO s -- and How could a fellow live without a COBOL ALTER statement? For those who forgot
          Message 4 of 8 , Mar 29, 2002
          • 0 Attachment
            --- In extremeprogramming@y..., Brian Christopher Robinson
            <brian@d...> wrote:
            > Things that scared me:
            >
            > o Saying that global variables shouldn't be used too often. How
            about not
            > at all?

            Bah humbug! Next you'll be saying we should avoid GOTO's -- and How
            could a fellow live without a COBOL ALTER statement?

            For those who forgot the good old days:
            The ALTER statement changes the destination of a GO TO statement.
            When the changed GO TO executes, it transfers control to new-proc
            instead of the procedure it previously referred to.

            Hey - why waste memory on a switch variable - just change the target
            address! Besides we are software gods. We write perfect code. No-
            one will ever wonder when the source says "GOTO A", how the debugger
            wound up at "B". (Nahh - we didn't have a debugger - it took too
            much memory, but you could single step from the console switches,
            and figure out where you were from the lights).

            > And that's only the first third or so fo the book. Were things
            really that
            > bad back in the day?
            >

            Its not bad - just different priorities - computer time cost a lot
            more than people time. And memory and cpu cycles were in short
            supply.

            I don't miss it.
          • Charlie Poole
            Brian, ... Thanks for the tip... ... We ve come a long way. I started out around 1970 and had to write my own multiplication and division routines. Talk about
            Message 5 of 8 , Mar 29, 2002
            • 0 Attachment
              Brian,

              > As a result of BookPool's 45% off Microsoft Press books this
              > month I picked
              > up Code Complete along with a few others books.

              Thanks for the tip...

              > I've read about 150 pages
              > of it so far and it is very scary. I am quite glad I got my CS degree in
              > 2000 and my first job after graduating began with an XP project
              > rather than
              > starting my career in 93 when this book was published..
              >
              > Things that scared me:
              >
              > o A whole chapter devoted to convincing people that they should use
              > "modules", equivalent to today's object. What's scary is that they would
              > need convincing.
              > o Saying that global variables shouldn't be used too often. How
              > about not
              > at all?
              > o A dead serious declaration that methods of 200 lines and longer are
              > easier to understand and more bug free than shorter ones.
              > o An example where McConnell admits to writing the line "node =
              > node.next"
              > everywhere in his program instead of having a method to encapsulate this
              > behavior of his linked list.
              > o The standard BDUF stuff, although this is to be expected.
              >
              > And that's only the first third or so fo the book. Were things
              > really that
              > bad back in the day?

              We've come a long way. I started out around 1970 and had to write
              my own multiplication and division routines. Talk about OAOO!

              I hope you're bearing in mind that it was the folks putting
              up with all the drawbacks of hardware, tools and techniques
              in each generation that invented the stuff for the next.

              So what are you doing for the programmers of 2020? :-)

              Charlie Poole
              cpoole@...
            • jeffgrigg63132
              ... Things were very scary back then. Things are still very scary now. But, fortunately, at least some of the worst abuses of the past have been reduced, and
              Message 6 of 8 , Mar 30, 2002
              • 0 Attachment
                --- Brian Christopher Robinson <brian@d...> wrote:
                > [...] Microsoft Press books [...] Code Complete [...]
                > [...] it is very scary. [...]

                > [...] Were things really that bad back in the day?

                Things were very scary back then. Things are still very scary now.
                But, fortunately, at least some of the worst abuses of the past have
                been reduced, and all but the worst coders should be dealing with
                higher level issues now.


                > Things that scared me:
                > o A whole chapter devoted to convincing people that they should use
                > "modules", equivalent to today's object. What's scary is that they
                > would need convincing.
                > o A dead serious declaration that methods of 200 lines and longer
                > are easier to understand and more bug free than shorter ones.

                To be successful with OO concept (or even just good modules),
                developers must muster the skill of abstraction.

                I've heard some good arguments form people who were against OO due to
                their experiences of small methods being bad "because you can't see
                what they're doing; everything's hidden in tiny little methods."

                What I found was that these people (or the coders who produced the
                code they were looking at) lacked strong abstraction skills. The
                point about "node = node->next" would be lost on them, because you
                have to abstract to the concept of "iterator" to see how things could
                and should be different.


                > o Saying that global variables shouldn't be used too often. How
                > about not at all?

                If memory serves (which it usually doesn't ;-) he even argues
                *against* doing the most trivial kind of refactoring -- changing the
                name of a local variable -- because of a bad experience one of his
                coders had where he obscured a global variable that happened to also
                be used by the same method. (Changed local 'Connection1' variable
                to 'Connection', which was the global variable's name.)

                I argue strongly that global variables should have annoyingly long
                names with some kind of well-defined naming standard prefix so that
                they stand out. He blamed the coder for introducing a bug
                by "carelessly and thoughtlessly" simplifying a local variable name.
                *I* blame the coder who made and used a global variable with a short
                one word common name!!!

                - jeff


                DOS Viruscan initated -- Windows found: Delete? (Y/y)
              • dhemeryy
                Hi Jeff, ... I can imagine another possibility: Once upon a time, if I didn t trust someone else s abstractions, I might want to see what s going on inside
                Message 7 of 8 , Mar 30, 2002
                • 0 Attachment
                  Hi Jeff,

                  > I've heard some good arguments form people who were against OO due
                  > to their experiences of small methods being bad "because you can't
                  > see what they're doing; everything's hidden in tiny little methods."
                  >
                  > What I found was that these people (or the coders who produced the
                  > code they were looking at) lacked strong abstraction skills.

                  I can imagine another possibility: Once upon a time, if I didn't
                  trust someone else's abstractions, I might want to see what's going on
                  inside the code.

                  These days, I'm more likely to write tests.

                  Dale
                • Bill de hÓra
                  ... Hash: SHA1 ... Maybe. Maybe some developers don t trust the abstractions given to them and want to know what s really going on behind the curtain. ... Is
                  Message 8 of 8 , Apr 1, 2002
                  • 0 Attachment
                    -----BEGIN PGP SIGNED MESSAGE-----
                    Hash: SHA1

                    > -----Original Message-----
                    > From: jeffgrigg63132 [mailto:jgrigg@...]
                    >
                    > To be successful with OO concept (or even just good modules),
                    > developers must muster the skill of abstraction.

                    Maybe. Maybe some developers don't trust the abstractions given to
                    them and want to know what's really going on behind the curtain.

                    > I've heard some good arguments form people who were against OO
                    > due to their experiences of small methods being bad "because
                    > you can't see what they're doing; everything's hidden in tiny
                    > little methods."

                    Is that as in "I can't follow the flow of execution" ?

                    Bill de hÓra

                    -----BEGIN PGP SIGNATURE-----
                    Version: PGP 7.0.4

                    iQA/AwUBPKiYZuaWiFwg2CH4EQIqTQCfeRDwiAWzueKVlSWCm3Pd7jWiycEAoKoa
                    JX7x6cByXEGUVB3K9rvYLxsK
                    =jmXv
                    -----END PGP SIGNATURE-----
                  Your message has been successfully submitted and would be delivered to recipients shortly.