Productivity in programming of C++ programmers

[Phlip]

Re: Productivity in programming of C++ programmers

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

http://www.google.com/search?q=sifu

Scroll down to "Kung Fu".

--
Phlip

http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces

[Phlip]

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]

http://www.ibras.dk/montypython/finalripoff.htm#Novel

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

[ChadBl]

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]

[David Hilsee]

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

[lilburne]

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

[Jerry Coffin]

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.

[Bob Hairgrove]

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

[ChadBl]

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]

[David]

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

[Siemel Naran]

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.

[Phlip]

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

http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces

[Siemel Naran]

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.

[Phlip]

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

http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces

[Phlip]

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

http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces

[David]

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