[OT] dealing with lower level programmers

B

Balog Pal

Ian Collins said:
That's a fair point but I was using the "typical" programmer as a
baseline, which was fair considering the original statement was "a good
programmer can be 100x productive as an average one"

Aha, I thought the comparision is about the edges. If the left point is
'average', no wonder you are in the swamp with discussion. As it is even
more arbitrary to pick up a supposed middle. As to that we need a good
estimate on the ration of the 'crap programmers'. What is IMO obvoiusly
huge, if you look at the applications too. Or if you calculate some weighed
contribuition, and the overall failure rate of projects (that is over half
in the last data I saw), it is easy to come up, the middle point still has
negative contribution. Or something close to zero. That can explain huge
figures in the diff.

IOW before bickering on figures, try to reach consensus what you call
average. ;-)
 
B

Balog Pal

Alf P. Steinbach said:
In fact, a recent career guide in Norwegian "Dagens Næringsliv", a leading
economics newspaper in Norway, cautioned strongly against doing too well
while at the lower rungs of the ladder because one is then viewed as a
threat both by co-workers and by one's boss, and reader comments were
uniformly positive that at last some reality was discussed.

"Some" reality? This is a fundamental thing, well described for long in
Peter principle.

In a workplace that has a hierarchy, and where the boss is not the owner, it
absolutely kicks.

An employee's first priority is his position in the majority of cases, not
some abstract values like (even if painted on each wall) like integrity,
quality, satisaction of the customer, etc.
 
B

Balog Pal

Noah Roberts said:
OK, this is pretty good analysis but one thing it leaves out maybe is the
time that a "bad" programmer can add to discussion time.

I'd approach from the other direction. The average programmer planted the
otiginal bug in the code, being unaware of stuff like 'you initialize
variables' 'you read the F*ing warnings', and so on. The bug caused the
10m or 60m or 10h or 20h or whatever much time that contributes nothing to
value.

The good guy just followed the WAY and submitted the code without those
bugs. (And very likely pushed some nearby fellows toward the WAY too.)

I observed organisations, especially bosses tend to not calculate with
prevention at all.
Instead, measuring 'hard work' in the amount of visible sweat. :(
 
I

Ian Collins

Pascal said:
_development_ _time_!

We are not discussing speed of compiled programs (we could and I could
provide benchmarks showing Lisp programs faster than their counterpart
C programs, but that's not the subject).
You said "the good programmer may also choose more productive tools".
Do you know any good Lisp compilers and tool chains for embedded targets?
 
P

Pascal J. Bourguignon

Ian Collins said:
You said "the good programmer may also choose more productive
tools". Do you know any good Lisp compilers and tool chains for
embedded targets?

"Embedded targets" is too vague.

For example, Common Lisp has been used in the Deep Space 1 sonde.
This is definitively "embedded" software for me. AFAIK, it was a
standard commercial CL implementation that was used.

http://ti.arc.nasa.gov/m/tech/rse/publications/papers/IEEE1999/Autonomy.pdf
http://www-aig.jpl.nasa.gov/public/papers/rax-results-isairas99.ps

For more restricted targets, Lisp can be used to actually generate the
code, without installing a whole implementation on the target. An
example of this kind of deployment would be in the game market, where
NaughtyDog generated a PS2 game with lisp.

http://www.franz.com/success/customer_apps/animation_graphics/naughtydog.lhtml

You don't put a C compiler in a PIC, there's no reason why you'd put a
Lisp compiler there either. But you might be able to produce the PIC
code more easily using tools written in Lisp than with a C compiler.
 
A

Andrew Tomazos

In answer to that, I'd point you to the original claim: "a good
programmer can be 100x productive as an *average* one".

So an experiment might be to take a randomly selected group of 10
programmers and compare their team output over ten day with the mythical
super programmer who should produce the same output in one.  A larger
sample size might give a better average..

I haven't got a lot of time unfortunately, so I must be brief.

In trying to understand where the 100x factor comes from consider:

- How long does it take to locate an elusive intermittent bug in a
large codebase? Are some people better/faster at this than others?
Why?

- When selecting an object model to implement a given interface/
contract, what impact on productivity will be seen by selecting a
really good one over just a mediocre one?

- How much more valuable is good software than average software?

- How much of an productivity impact does creating a tool to do a
repetitive task have over just doing the task manually?

- Do some people find reading other peoples code (reverse engineering)
easier than others? Do well-chosen tools help? How about a near
photographic memory? How about a speed reader?

- If someone were to constantly type at 100 wpm for 10 hours straight,
how many lines of code could they write? How many lines of code does
an average programmer write in 10 hours? Why the huge difference?
What are they doing all this time they are not typing away?

The fact is that the bottleneck in writing software is to a large
extent "creative", in the same way that a mathematician thinks of
proofs by being "creative". It is not well-understood why some people
are better at this than others, even two programmers with equal
experience and the same access to training/eduction/mentorship can
exhibit large differences in talent. Some conjecture that it is the
result of early childhood or genetics or some combination thereof.

Have a look at the results of one of the completed marathon matches at
TopCoder.com. You can see the problem statement, the finalists and
their code. Notice how the winning entry varies both in performance
and how the code is written from say one of the average entries.
Clearly this is just a microcosm, but you can still tangibly see the
"100x phenomenon" at work.

Now consider:

1. Get the winner of the recent TopCoder marathon match "Fred".
2. Get the next problem statement.
3. Give Fred a day to do it.
4. Assemble a team of 10 average programmers - give them 10 days to do
it.
5. See who wins.

My money is on Fred.

Really have to go now!!

Enjoy,
Andrew.
 
J

Jerry Coffin

J

Jerry Coffin

[ ... ]
Have a look at the figure #3 on page 9 of this report:

http://www.haskell.org/papers/NSWC/jfp.ps

Notice that it has been written by a Haskell advocate. Compare the
development time of Lisp vs other programming languages...

To get anything meaningful, you need to look at more than just that
one figure. First, you need to take into account that this was
development of a prototype, not real code. Second, you need to look
at the date on the paper -- 1994. Third, you also have to note that
none of the languages used was really Lisp as most people would
understand the term -- the only one that even resembled Lisp was
"relational lisp", which is: "[...] a language developed at ISI, is
essentially Lisp enhanced with notions of ?relational abstraction:? a
database-like facility having a logic-programming feel." Finally,
it's worth noting that they openly admit that the programs weren't
seriously tested, and "some of the prototypes did not actually
execute" (though they don't seem to identify which those were).

The date means what it calls C++ bore little resemblance to what we
use today -- in particular, its standard library was probably just a
C library plus iostreams. For a large project, that wouldn't
necessarily make a huge difference, but in such a small prototype as
this, the time and code to handle something as simple as a linked
list makes a _huge_ difference.

The prototype nature (and possible lack of execution) leaves us with
little assurance that the Lisp prototype actually worked. Given that
they clearly state that the author of the Lisp prototype attended a 4
hour kickoff meeting, but only reports 3 hours for development, means
that (at least as such things are normally measured) the three hours
is clearly incorrect -- four hours is the absolute minimum, and seven
is much more likely.

In contrast to any of the others, they note that the C++ version
included not only the program itself, but a ~600-line test harness.
That tends to suggest that 1) unlike at least some of the others, the
C++ version probably did execute, and 2) was probably much closer to
production code.

As far as the Lisp usage goes, we're left with insufficient
information to guess how much difference it's deviation from
"normal" Lisps made. First, we don't really have a good idea of what
"essentially Lisp" means, and second we don't know whether, and if so
how much, they used the relational capability of the language. If one
were to use CL (for example) the development time _might_ be almost
identical -- but it might just about easily be dramatically longer.

All in all, it's an interesting paper, and I'm glad you posted the
link -- but I don't think it provides much support for conclusions
about C++ or Lisp.
 
B

Balog Pal

Now consider:

1. Get the winner of the recent TopCoder marathon match "Fred".
2. Get the next problem statement.
3. Give Fred a day to do it.
4. Assemble a team of 10 average programmers - give them 10 days to do
it.
5. See who wins.
My money is on Fred.
<<

Better yet, define the accept requirements harshly. [Without telling, as it
must be the notm, isn't it?]. I.e. that you will pass the 'product' all
kinds of inputs, and a single crash or misbehavior is considered failure.

"Fred" will likely create something, in whatever time, and the team of
monkeys will nus never come up with an acceptable thing. What is the ratio
then?

IMO the camp talking about little differences just cheat in the result by
assuming the low-end people still work wth knowledgeable colleagues, who do
the code reviews and possibly wash up afterwards to. It is easy to be
'productive' doing a small portion of the job.
 
J

Jerry Coffin

[ ... ]
The prototype nature (and possible lack of execution) leaves us with
little assurance that the Lisp prototype actually worked. Given that
they clearly state that the author of the Lisp prototype attended a 4
hour kickoff meeting, but only reports 3 hours for development, means
that (at least as such things are normally measured) the three hours
is clearly incorrect -- four hours is the absolute minimum, and seven
is much more likely.

After more reading, it looks like the Ada 9x prototype did not
execute. They don't specify that the others all did, but lacking any
evidence to the contrary, it's probably fair to say that all the
others did actually execute.
 
B

Balog Pal

Jerry Coffin said:
You may have seen it before, but I'm reminded of the parable of the
two programmers:

http://www.csd.uwo.ca/staff/magi/personal/humour/Computer_Audience/Th
e%20Parable%20of%20the%20Two%20Programmers.html

Fun (and funny) but with quite a bit of truth as well...

Oh yeah :(

Also there was a presentation 'rowers' circiling around at my last worklpace
having a French team vs. a Japanese. Later I discovered versions of it on
the net, having GM and Toyota and some others. Here's a neutral versiuon:

http://www.nteu9.org/membership/teamrace.pdf

Too bad that the more things change the more they stay the same.
 
I

Ian Collins

Balog said:
IMO the camp talking about little differences just cheat in the result by
assuming the low-end people still work wth knowledgeable colleagues, who do
the code reviews and possibly wash up afterwards to. It is easy to be
'productive' doing a small portion of the job.

"low-end people" are, by definition, below average. For the nth time
for those who aren't paying attention, I'll restate the original claim:

"a good programmer can be 100x productive as an *average* one".
 
B

Balog Pal

Ian Collins said:
"low-end people" are, by definition, below average. For the nth time for
those who aren't paying attention, I'll restate the original claim:

"a good programmer can be 100x productive as an *average* one".

Come on, Ian!

For that statement to mean anything on earth you shall fill with meaning the
terms:
- "good programmer"
- "average programmer"
- "productiveness of the programmer"

Until that the whole debate is no different from "how many angels can dance
on the top of a needle".

If anyone here actually means it, pleas state at least what you want to mean
by average. In simple language it has no single meaning. Or if you mean the
math function "average" applied, then state to what measure. Until then we
can;t tell who is above/below and whether the set is not actually empty.
Why assume a certain spread to an unknown measure.

(Or better yet let's admit it's just a play of words, that just must not be
taken seriously, and especially getting annoyed at each other.)
 
J

Jerry Coffin

[email protected] says... said:
For that statement to mean anything on earth you shall fill with
meaning the terms:
- "good programmer"
- "average programmer"
- "productiveness of the programmer"

Until that the whole debate is no different from "how many angels can dance
on the top of a needle".

For the current discussion, all of those really revolve around the
last -- i.e. what is meant by productivity. I'd measure it in terms
of function points implemented per unit of time. Other people might
prefer to use lines of code -- under the right circumstances (within
a given project, all using the same language, etc.) that can be
reasonable, but especially across languages it becomes difficult to
compare meaningfully.

From there, about all you really need to define for average is what
average you want to use: the arithmetic mean, the harmonic mean, the
geometric mean, the median, the mode, etc. If you were going to use
the mode, you'd also have to define your strata as well, but I don't
think it's suitable here, so I wouldn't bother. While most people
find the arithmetic mean the most understandable, given the claimed
variability, the geometric mean would probably be a better choice.

In this context, it seems nearly certain (at least to me) that "good
programmer" was intended to mean "highly productive" or (probably)
"most productive."
 
G

Gerhard Fiedler

Ian said:
In answer to that, I'd point you to the original claim: "a good
programmer can be 100x productive as an *average* one".

So an experiment might be to take a randomly selected group of 10
programmers and compare their team output over ten day with the
mythical super programmer who should produce the same output in one.
A larger sample size might give a better average..

10 programmers working for 10 days is /not/ 100 times one programmer
working for one day. This is a classic: see The Mythical Man-Month, if
it shouldn't be obvious. For coordinating the efforts of 10 programmers,
10 days is not much.

A better test would be to give the 10 programmers each 4 months (100
working days), and see how the classification of all 11 looks like. Or
make teams of 2 and give them 2 months.

Gerhard
 
I

Ian Collins

Balog said:
Come on, Ian!

For that statement to mean anything on earth you shall fill with meaning the
terms:
- "good programmer"
- "average programmer"
- "productiveness of the programmer"

Until that the whole debate is no different from "how many angels can dance
on the top of a needle".

I think that was my point! I didn't make the original claim.
 
I

Ian Collins

Gerhard said:
10 programmers working for 10 days is /not/ 100 times one programmer
working for one day. This is a classic: see The Mythical Man-Month, if
it shouldn't be obvious. For coordinating the efforts of 10 programmers,
10 days is not much.

The suggestion as no more ridiculous that the original claim!
 
J

James Kanze

James Kanze wrote:
James, have you read
"CMMI or Agile: Why Not Embrace Both!"?

A long time ago. But that's not really the point. The most
important aspects of CMMI address a higher level---not so much
what to do, but how to decide what to do. Thus, CMMI doesn't so
much say that you have to use code reviews instead of pair
programming, but rather specifies criteria by which you can make
such a choice. Some aspects of agile programming can probably
be adopted into any process; some may even improve it (depending
on the rest of the process). But you don't adopt them because
they've been sold as agile; you adopt them as part of a larger
process, because they result in a measurable improvement in your
productivity.

What I miss in the agile programming literature is this
measuraable. There are a lot of claims, but they all seem to be
comparing with using no process at all, and they all seem to be
more feeling than actual measurement.
 
J

James Kanze

That is a childish misrepresentation of what I said. If you
don't understand where the statement "a good programmer can be
100x productive as an average one" comes from than my guess is
you haven't worked with any *really* good programmers.

And that's insulting, because I have worked with really good
programmers. A lot of them. And I know a lot more, including
some of the very best (go to a meeting of the ISO C++ committee,
and you'll see what I mean), none of whom claims to be able to
write a good program without help---in fact, I find it a
consistent characteristic of the very best (people like
Stroustrup, for example) that they are generally the quickest to
acknowledge that good programs require teamwork, that you can't
do it alone.
Surely you don't claim to have worked with every programmer on
Earth?

I'm an independent consultant, and have been for 25 years. I've
worked with a very large number of different people. And I know
enough about human beings to know the expected degree of
variance. I repeat: Superman only exists in comic books. No
one is 100x better than "average", in anything. No one is
perfect, and capable of producing a perfect work, in any field.
In most engineering fields, this has been acknowledged, and
there is often even a legal requirement for review. In software
engineering, we're not there yet; the fact that bad software
is tolerated, and even widely used, is proof of that. (And of
course, review isn't perfect either, since the reviewers are
also fallible humans. So we occasionally have bridges that
fail. The percentage of bad bridges, however, seems to be to be
a lot less than the percentage of bad software.)
Given that you have not, why isn't it possible that
some of the programmers you have not worked with are
significantly better than the best programmer you have worked
with? You must concede it as, at a minimum, logically
possible.

As I said elsewhere, Superman only exists in comic books. I've
worked with enough different programmers to be able to have a
very good idea as to the variance. Some are five times more
productive, no doubt. I wouldn't exclude even ten times more
productive. But that's an upper limit.

Beyond programming: take any human activity, and you'll not find
people 100 times better than the average. (For activities like
programming, which require special training, the "average" of
trained people, of course.)
Given that it is possible, why do you so fervently deny it?

Because it isn't possible. Superman only exists in comic books.
People (in general, not just in programming) don't show that
degree of variance in ability, at least not in the positive
direction. (It's an interesting question why. A genetic defect
or some such can cause extreme variance, but it's always
negative.)
I would quite happily accept you saying that you have not seen
the phenomenon - but you are claiming that it doesn't exist
because you haven't seen it. When someone digs a trench like
this they usually have a vested interest in their position
being true:
The fact is a lot of engineering process designers and project
managers would love it if programmers were homogeneous
interchangeable parts.

There's a difference between homogeneous and a 100x difference.
Programmers aren't homogeneous. Different programmers are most
skilled in different aspects, and even when they're best area is
the same, there is a distinct, measurable difference in their
abilities there. But with the exception of some (very few)
remarkably bad people, the difference isn't more than about five
times.

Note that different programmers have different skill sets. As a
consultant, I've often been used to provide "missing"
skills---the permanent employees were better than me in
application domain programming, but weren't that good in other
areas, like threading, or low level library stuff. In a very
real sense, saying that x is 100x, or even just five times,
better at programming doesn't mean anything, since different
aspects of programming require different skills.

When you see someone performing 100x better than someone else,
you'll find that the environment he's working in plays a major
role, and not just his competence.
It would make a managers job so much easier that some even try
to bury their head in the sand and pretend that this is the
case. X programmers produce Y lines of code with Z errors. :)
Unfortunately it just doesn't gel with reality.

That's for sure. Different programmers have different skill
sets, and can vary globally in competence. Just not to the
degree you claim.
Programmers vary greatly in their level of productivity (yes
as much as 100x).

Different environments can cause a 100x difference in the
productivity of a single programmer. (At least twice, I've
worked in environments which guaranteed negative performance,
regardless of how skilled the programmer.)
I repeat: I have seen this firsthand, I have heard firsthand
account, it has been written about in books.

I've heard a lot of war stories, too. People (myself included)
like to exagerate, and memory can play cruel tricks. That's why
measurement is so important.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,764
Messages
2,569,565
Members
45,041
Latest member
RomeoFarnh

Latest Threads

Top