Productivity in programming of C++ programmers

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Phlip

    #16
    Re: Productivity in programming of C++ programmers

    Zilsch wrote:
    [color=blue]
    > WTF is "sifu"?[/color]



    Scroll down to "Kung Fu".

    --
    Phlip
    Industrial XP: Extreme Programming, XP, Agile Software Development, Agile Methods.





    Comment

    • Phlip

      #17
      Re: Productivity in programming of C++ programmers

      Phlip wrote:
      [color=blue]
      > David Hilsee wrote:
      >[color=green]
      > > ...on the next revision of the standard so he can gain a surprise boost[/color][/color]
      when[color=blue][color=green]
      > > it
      > > is released. Stay tuned for more productivity updates on The Programmer
      > > Racing Channel.[/color]
      >
      > hehehe - look up "Novel Writing" by Monty Python ;-)[/color]


      [color=blue]
      > --
      > Phlip
      > http://industrialxp.org/community/bi...UserInterfaces[/color]


      Comment

      • ChadBl

        #18
        Re: Productivity in programming of C++ programmers

        Simple formulas...

        Developer + cubicle (noise, distractions) = nonproductive
        Developer + newest compilers or latest tech fads = nonproductive

        Developer + quiet office = productive
        Developer + standard tools and compiler that she's/he's used for the last
        few years = productive

        A good developer will take more time to do a job right the first time around
        (measure twice, cut once). Basically, you get what you pay for, and that
        includes allocating enough time for a developer to write good code.


        "N4M" <dnguyenk@yahoo .com> wrote in message
        news:6e8e8a14.0 408090411.2b68f 5e1@posting.goo gle.com...[color=blue]
        > Dear,
        > May I ask how productivity of a(C++) programmer can be measured?
        > If it is measured by number of code lines per day, what are the
        > estimated productivity of a programmer at beginer, intermediate (Me),
        > advance, master, guru,and sifu (B.Stroustrup, H.Sutter, S. Meyer)?
        > Thanks for your guidance.
        > NguyenMai
        >
        > P/S: Similar post has been sent to comp.lang.c++.m oderated (probably
        > takes longer time)[/color]


        Comment

        • David Hilsee

          #19
          Re: Productivity in programming of C++ programmers

          "Phlip" <phlip_cpp@yaho o.com> wrote in message
          news:rHYRc.1982 $FV3.998@newssv r17.news.prodig y.com...[color=blue]
          > Phlip wrote:
          >[color=green]
          > > David Hilsee wrote:
          > >[color=darkred]
          > > > ...on the next revision of the standard so he can gain a surprise[/color][/color][/color]
          boost[color=blue]
          > when[color=green][color=darkred]
          > > > it
          > > > is released. Stay tuned for more productivity updates on The[/color][/color][/color]
          Programmer[color=blue][color=green][color=darkred]
          > > > Racing Channel.[/color]
          > >
          > > hehehe - look up "Novel Writing" by Monty Python ;-)[/color]
          >
          > http://www.ibras.dk/montypython/finalripoff.htm#Novel[/color]

          Now _that's_ funny. :-)

          --
          David Hilsee


          Comment

          • lilburne

            #20
            Re: Productivity in programming of C++ programmers



            Pete Becker wrote:[color=blue]
            >
            >
            > By that measure, my productivity is often negative. I consider those to
            > be very good days.
            >[/color]

            We only count the amount of code removed as a measure of productivity.
            The one who removes the most is given the title "Edward Scissorhands".


            Comment

            • Jerry Coffin

              #21
              Re: Productivity in programming of C++ programmers

              dnguyenk@yahoo. com (N4M) wrote in message news:<6e8e8a14. 0408090411.2b68 f5e1@posting.go ogle.com>...[color=blue]
              > Dear,
              > May I ask how productivity of a(C++) programmer can be measured?[/color]

              You can ask, but about the only accurate answer I know is
              "subjective ly."
              [color=blue]
              > If it is measured by number of code lines per day, what are the
              > estimated productivity of a programmer at beginer, intermediate (Me),
              > advance, master, guru,and sifu (B.Stroustrup, H.Sutter, S. Meyer)?[/color]

              Ultimately, what you want to measure is the value of what is produced.
              Line counts have already been sufficiently excoriated to render my
              doing so superfluous.

              Feature counts have been suggested as an alternative, but IMO, they're
              only marginally better in most cases. The problem is that a poor
              design will often be composed of a large number of discrete features.
              A better design will tend to have fewer features, but each will be
              more general and they'll work together better -- in fact, the ability
              to "compose" features is often the most important feature of all.

              As such, when looking at a significant piece of code, the feature
              count will often have about the same significance as the line count
              (in fact, the two often roughly mirror each other).

              Unfortunately, most other objective measures seem little or no better,
              at least to me. People have been studying software metrics of various
              sorts for decades now, but I've yet to see one that impressed me as
              being even close to as good as a pair of experienced eyes looking at
              the code. One of the major problems is that while many software
              metrics do reasonably well for specific types of code, most of them
              run into major problems for other types of code.

              Just for example, one of the oldest and best-known software metrics is
              McCabe Cyclometric Complexity. This is based on a count of the number
              of decision points in a module (e.g. if, for, while statements).
              Unfortunately, even with relatively average types of code, the
              correlation between its result and the maintainability of the code is
              close to zero, and seems to be negative about as often as positive.
              This is poor correlation at best, but if you add (for one example)
              even a trivial finite state machine, it can blow up entirely,
              basically doing its best to tell you that FSMs (in general) are evil
              and impossible to read.

              --
              Later,
              Jerry.

              The universe is a figment of its own imagination.

              Comment

              • Bob Hairgrove

                #22
                Re: Productivity in programming of C++ programmers

                On 10 Aug 2004 14:28:32 -0700, jcoffin@taeus.c om (Jerry Coffin) wrote:

                [snip][color=blue]
                >
                >Feature counts have been suggested as an alternative, but IMO, they're
                >only marginally better in most cases. The problem is that a poor
                >design will often be composed of a large number of discrete features.
                >A better design will tend to have fewer features, but each will be
                >more general and they'll work together better -- in fact, the ability
                >to "compose" features is often the most important feature of all.
                >
                >As such, when looking at a significant piece of code, the feature
                >count will often have about the same significance as the line count
                >(in fact, the two often roughly mirror each other).[/color]

                What about "feature creep"?

                I would say that, ideally, "line creep" should grow logarithmically
                with "feature creep", not directly proportional (or even exponential).

                If this can be obtained, maximum efficiency has been reached.


                --
                Bob Hairgrove
                NoSpamPlease@Ho me.com

                Comment

                • ChadBl

                  #23
                  Re: Productivity in programming of C++ programmers

                  That '3rd attempt is gold' is what should be done. It's like writing a
                  magazine article -- the first time through is a rough draft, then you go
                  over it and use better words in some places, fix the parts where you're
                  taking too long to get to the point, and you end up with a working copy. The
                  third time around, you do more tweaks to the article, and then you have
                  gold.

                  Developing software is the same way. Reworking your code 3 times is part of
                  a *single* process, and if you're not given enough time and the correct
                  environment to complete the entire cycle, then that code will,
                  understandably, be subpar for what you can really produce.

                  However, in the real world (business run by the whims of marketing), the
                  focus is usually placed on producing software in rapid quantity, not
                  quality. So I guess the original question of how to measure Productivity
                  isn't going to have a single answer, because each company has its own goals
                  in terms of software production -- they either want so-so software shoved
                  out of the door once every 6 months so that a fresh version is always on the
                  shelves, or they want to spend a year to make it as reliable and usable as
                  possible.


                  "Pete Becker" <petebecker@acm .org> wrote in message
                  news:4118D1A7.7 2A68C45@acm.org ...[color=blue]
                  > ChadBl wrote:[color=green]
                  > >
                  > > A good developer will take more time to do a job right the first time[/color][/color]
                  around[color=blue]
                  >
                  > I consider myself a good developer, and I generally that I do the best
                  > job the third time around. The first two attempts are mostly for
                  > learning.
                  >
                  > --
                  >
                  > Pete Becker
                  > Dinkumware, Ltd. (http://www.dinkumware.com)[/color]


                  Comment

                  • David

                    #24
                    Re: Productivity in programming of C++ programmers

                    On Mon, 9 Aug 2004 12:11:57 UTC, dnguyenk@yahoo. com (N4M) wrote:
                    [color=blue]
                    > Dear,
                    > May I ask how productivity of a(C++) programmer can be measured?
                    > If it is measured by number of code lines per day, what are the
                    > estimated productivity of a programmer at beginer, intermediate (Me),
                    > advance, master, guru,and sifu (B.Stroustrup, H.Sutter, S. Meyer)?
                    > Thanks for your guidance.
                    > NguyenMai
                    >
                    > P/S: Similar post has been sent to comp.lang.c++.m oderated (probably
                    > takes longer time)[/color]

                    The productivity of "a programmer" can be measured by any number of
                    factors. The only useful measurements, IMO, are the features added,
                    the quality of the code, the quality of the product, and the problems
                    found in the field (negative, of course).

                    I would certainly hope that your goal for the day is not to write
                    100 (or whatever amount of) lines of code. I would hope that at whatever
                    skill rating you are at, that there is a plan to accomplish a certain
                    number of tasks in the coming days and that you have a specific few to
                    accomplish in your next session. Sessions can consist of coding, designing,
                    documenting, verifying, or whatever mix is reasonable.

                    At the low end I would expect the developer to spend time deciding what
                    relatively small task to accomplish, how to accomplish that task, testing
                    and verifying that the code works, and then perhaps rewriting it into a
                    form that could be used in the desired project. Once complete, another
                    task or so could be added.

                    Experience and accumulated tools can enhance the size of the tasks
                    accomplished. The more advanced developers would show that they can
                    combine a larger number of tasks and relationships and design ever larger
                    projects, and then build the project in pieces that make sense for the
                    overall project. Its also helpful to be able to document the design
                    so that others might be able to help create the overall project.

                    David

                    Comment

                    • Siemel Naran

                      #25
                      Re: Productivity in programming of C++ programmers

                      "Peter van Merkerk" <merkerk@deadsp am.com> wrote in message
                      news:2npan1F34r t7U1@uni-
                      [color=blue]
                      > Lines of code is the worst metric to measure a programmers productivity.
                      > It stimulates wrong behavior; you don't want programmers to maximize the
                      > number of lines of code to accomplish a certain task.[/color]

                      Good point. Consider the concept of refactoring. Writing un-refactored
                      code usually leads to code harder to maintain, yet it is easier to write.
                      Writing factored code is more difficult, yet the resulting code is shorter
                      and easier to maintain.

                      Often, to refactor we will write out the main generic algorithm and capture
                      the specific details varying between specific algorithms as small virtual,
                      template, or parameterized functions.


                      Comment

                      • Phlip

                        #26
                        Re: Productivity in programming of C++ programmers

                        Siemel Naran wrote:
                        [color=blue]
                        > Good point. Consider the concept of refactoring. Writing un-refactored
                        > code usually leads to code harder to maintain, yet it is easier to write.
                        > Writing factored code is more difficult, yet the resulting code is shorter
                        > and easier to maintain.[/color]

                        One can make refactoring slightly easier by deliberately seeding a design
                        with a bit of cruft, then taking it out.

                        For example, to pass a test, you make the minimum edit. Don't yet reconcile
                        the new ability with all the existing code. If you need to clone an entire
                        function and change one line, if that passes the test, do it.

                        When you get a green bar, you are free to clean up the design. Perform
                        minimal Extract Method Refactors on the common code in those two functions,
                        and write new little delegating methods. The two lines you change are now
                        all that's left-over. Give this situation a better structure, and /voila/:
                        You have a new design. And you might not notice just when growing that new
                        design involved other regions of the code.

                        (From here, see my "Contractiv e Delegation" post now showing on a
                        news:comp.objec t near you.)

                        --
                        Phlip
                        Industrial XP: Extreme Programming, XP, Agile Software Development, Agile Methods.



                        Comment

                        • Siemel Naran

                          #27
                          Re: Productivity in programming of C++ programmers

                          "Phlip" <phlip_cpp@yaho o.com> wrote in message news:55iSc.690[color=blue]
                          > Siemel Naran wrote:[/color]
                          [color=blue][color=green]
                          > > Good point. Consider the concept of refactoring. Writing un-refactored
                          > > code usually leads to code harder to maintain, yet it is easier to[/color][/color]
                          write.[color=blue][color=green]
                          > > Writing factored code is more difficult, yet the resulting code is[/color][/color]
                          shorter[color=blue][color=green]
                          > > and easier to maintain.[/color]
                          >
                          > One can make refactoring slightly easier by deliberately seeding a design
                          > with a bit of cruft, then taking it out.
                          >
                          > For example, to pass a test, you make the minimum edit. Don't yet[/color]
                          reconcile[color=blue]
                          > the new ability with all the existing code. If you need to clone an entire
                          > function and change one line, if that passes the test, do it.
                          >
                          > When you get a green bar, you are free to clean up the design. Perform
                          > minimal Extract Method Refactors on the common code in those two[/color]
                          functions,[color=blue]
                          > and write new little delegating methods. The two lines you change are now
                          > all that's left-over. Give this situation a better structure, and /voila/:
                          > You have a new design. And you might not notice just when growing that new
                          > design involved other regions of the code.
                          >
                          > (From here, see my "Contractiv e Delegation" post now showing on a
                          > news:comp.objec t near you.)[/color]

                          Is there anything wrong if we write factored code from the start? For
                          example, if I know in my initial design that I want to support both yearly
                          and transaction items, then I can immediately write an item class, then
                          derive transaction and yearly item from it. Any harm?

                          In a similar manner, I may make functions inline before profiling. For
                          example, std::complex::r eal() would be inline. Mostly because it's easier
                          to write, uses fewer lines of code. But in any case, it seems the inline
                          should make things faster.


                          Comment

                          • Phlip

                            #28
                            lazy inline [Was: Productivity in programming of C++ programmers]

                            Siemel Naran wrote:
                            [color=blue]
                            > In a similar manner, I may make functions inline before profiling. For
                            > example, std::complex::r eal() would be inline. Mostly because it's easier
                            > to write, uses fewer lines of code. But in any case, it seems the inline
                            > should make things faster.[/color]

                            Low level code details (exception safety, const correctness, smart pointers,
                            copy operators, namespaces) can't be tested-first. Just write them.

                            In the case of "inline", you mean writing member function definitions inside
                            their classes. So answer this: Why are the classes in header files? Do you
                            have any classes in header files that could be in .cpp files?

                            --
                            Phlip
                            Industrial XP: Extreme Programming, XP, Agile Software Development, Agile Methods.



                            Comment

                            • Phlip

                              #29
                              TDD [Was: Productivity in programming of C++ programmers]

                              Siemel Naran wrote:
                              [color=blue]
                              > Is there anything wrong if we write factored code from the start?[/color]

                              In pure TDD theory, yes. In practice, if I write the same program three
                              times, the third time needs less screwing around, and the result's still
                              better. Upfront planning works the same.
                              [color=blue]
                              > For
                              > example, if I know in my initial design that I want to support both yearly
                              > and transaction items, then I can immediately write an item class, then
                              > derive transaction and yearly item from it. Any harm?[/color]

                              Those are features. Yes there is harm.

                              Given a hard problem, TDD generates a solution, with a firm design hosting
                              flexible bug-free features, sooner than expected. This is why Agile
                              processes fear too much abstract design planning. Complexity that's too easy
                              to add becomes hard to remove.

                              "Designing" means organizing the relations between the structure of objects
                              in memory and their behavior in time. Structure is bone, behavior is muscle,
                              and perfecting their design is difficult. The best way to seek simplicity is
                              to start with it.

                              The most important kind of duplication to fold is definitions of behavior.
                              Folding them together forces structures to grow new flexibilities. Mature XP
                              projects do _not_ refactor mercilessly, despite engineers are _required_ to
                              refactor when they see poor code quality. They don't. Adding new features
                              requires extending the existing design, just as if it had been brilliantly
                              planned.

                              These pressures force code to follow a curve of minimum complexity. Add a
                              feature, and the code puffs up. Air bubbles form in it.

                              If you then add another feature, the air bubbles harden, becoming more
                              difficult to remove.

                              If you instead refactor to force out any speculative code, the effect is
                              like hitting your substance with a big heavy hammer. You crush out all those
                              air bubbles. When you add the next feature, it has less chances of more air
                              bubbles, and less chances of them hardening.

                              --
                              Phlip
                              Industrial XP: Extreme Programming, XP, Agile Software Development, Agile Methods.



                              Comment

                              • David

                                #30
                                Re: Productivity in programming of C++ programmers

                                On Wed, 11 Aug 2004 05:51:37 UTC, "Siemel Naran"
                                <SiemelNaran@RE MOVE.att.net> wrote:
                                [color=blue]
                                > "Phlip" <phlip_cpp@yaho o.com> wrote in message news:55iSc.690[color=green]
                                > > Siemel Naran wrote:[/color]
                                >[color=green][color=darkred]
                                > > > Good point. Consider the concept of refactoring. Writing un-refactored
                                > > > code usually leads to code harder to maintain, yet it is easier to[/color][/color]
                                > write.[color=green][color=darkred]
                                > > > Writing factored code is more difficult, yet the resulting code is[/color][/color]
                                > shorter[color=green][color=darkred]
                                > > > and easier to maintain.[/color]
                                > >
                                > > One can make refactoring slightly easier by deliberately seeding a design
                                > > with a bit of cruft, then taking it out.
                                > >
                                > > For example, to pass a test, you make the minimum edit. Don't yet[/color]
                                > reconcile[color=green]
                                > > the new ability with all the existing code. If you need to clone an entire
                                > > function and change one line, if that passes the test, do it.
                                > >
                                > > When you get a green bar, you are free to clean up the design. Perform
                                > > minimal Extract Method Refactors on the common code in those two[/color]
                                > functions,[color=green]
                                > > and write new little delegating methods. The two lines you change are now
                                > > all that's left-over. Give this situation a better structure, and /voila/:
                                > > You have a new design. And you might not notice just when growing that new
                                > > design involved other regions of the code.
                                > >
                                > > (From here, see my "Contractiv e Delegation" post now showing on a
                                > > news:comp.objec t near you.)[/color]
                                >
                                > Is there anything wrong if we write factored code from the start? For
                                > example, if I know in my initial design that I want to support both yearly
                                > and transaction items, then I can immediately write an item class, then
                                > derive transaction and yearly item from it. Any harm?[/color]
                                <snip>

                                I work that way. If you have a clear idea what portion of the code
                                should be abstracted you may do so. It might be best to keep the design
                                simple in the generic portion so as to minimize the time you need to
                                code up a single task that now has a few extra concepts embedded. I
                                leave lots of comments (//@@@ in C++) that let me know where I've left
                                incomplete concepts for further development. As for knowing when some
                                concept may need to be generalized, that may be known in advance,
                                become obvious sometime later, or never really be needed. We just need
                                to insure that we don't over develop concepts and get away from our
                                desired work.

                                David

                                Comment

                                Working...