[OT] dealing with lower level programmers

[Keith H Duggar]

Yes - but nothing that effects the validity of the point.

On the contrary, it affects our ability to independently evaluate
and verify your claims. Without that we can't decide the validity
of your point (since it was just a collection of anecdotal claims
as opposed to say a deduction from shared beliefs).

KHD

 

[Andrew Tomazos]

On the contrary, it affects our ability to independently evaluate
and verify your claims. Without that we can't decide the validity
of your point (since it was just a collection of anecdotal claims
as opposed to say a deduction from shared beliefs).

You are correct. It is indeed merely eye witness testimony. It is up
to you how much you are swayed by it. From my point of view, I know
it's valid. From yours, I guess you can't be certain - although I
can't think what I would gain by making stuff like this up.
-Andrew.

 

[James Kanze]

Interesting. While the bug count indeed must be reduced, I
wouldn't say that's the most important factor of code quality.
I would put code maintainability first.

Both are important. It's just that the error count is easiest
to measure.

But anyways, your example doesn't involves more than one
programmer. It's good to have testers. And perhaps other
kinds of people in a team around a programmer.

OK. I should have used some other word than programmer,
perhaps, although in the places I've worked, the testers were
also programmers. But I was talking about the total production
of the code, which does involve much more than just coding.

Of course, in order to ensure maintainability, you need code
review by people with the same profile as those who will be
called on to maintain the code, which means that they're
qualified as programmers, even if they aren't actually
"programming" when doing the review.

The important fact is that the final product is a team effort.

That's basically what is advocated in The Mythical Man Month
actually.

Amongst other things. That you need a team, and that not
everyone in the team should have the same qualifications.

 

[Christof Donat]

I don't think a professional programmer can succeed without

I'm sorry, but it's a proven fact.

Beware of people who claim something was a "proven fact".

Note that
working in a team is a necessary condition, but not necessarily
a sufficient one.

Well, if you are working in a team, then teamwork is necessary. There are
types of Software that can usually not be developed alone, because of the
complexity of the whole thing. There are very many Programmers that can not
work alone, because they either are good at Software Design or at coding or
at project management.

Nevertheless there are people who are equally good at project management,
software architecture and coding. It is not the usual case, but they can
produce high quality software alone. Sometimes they don't do it alone,
because the effort they are working on is better solved in a team.

Christof

 

[James Kanze]

The software in question won numerous high profile awards in
the face of competition, and people described themselves as
"huge fans" of it. It was noted not only for its nice user
interface, but for its amazing robustness. It was most
certainly good software. Its existence disproves your
statement.

And of course, you won't tell us what it was, or give us any
other means of verifying your claims. (Windows NT also won some
awards, and a number of people liked it, but it's hardly what I
would call good software.)

[...]

It has been known for some time that good programmers can be
100x effective than average ones.

It has been known for some time that the world is flat, too.
Actual measurements, of course, have proven the opposite, but
that doesn't bother some people.

 

[James Kanze]

Beware of people who claim something was a "proven fact".

Because they might be right?

Well, if you are working in a team, then teamwork is
necessary. There are types of Software that can usually not be
developed alone, because of the complexity of the whole thing.
There are very many Programmers that can not work alone,
because they either are good at Software Design or at coding
or at project management.

There are, in fact, no human beings who are perfect, and don't
make mistakes. An effectively managed team can reduces these
significantly, however, because the mistakes of one person will
be caught and corrected by another.

Nevertheless there are people who are equally good at project
management, software architecture and coding.

That's true, but only in a negative sense. (There are people
who are totally incompetent at all three.) No one can shine in
all possible areas, however.

But that's not the point. No one is perfect in any area. We
all make mistakes. Having some one else review our work catches
most of those mistakes (supposing that person is competent as
well); the mistakes he makes (the points he misses in the
review) will not be the same ones we make. (Statistically, at
least.)

 

[Ian Collins]

But that's not the point. No one is perfect in any area. We
all make mistakes. Having some one else review our work catches
most of those mistakes (supposing that person is competent as
well); the mistakes he makes (the points he misses in the
review) will not be the same ones we make. (Statistically, at
least.)

Which is a good argument for pair programming!

 

[Christof Donat]

Hi,

Because they might be right?

Because they never are.

Nothing can be a proven fact because any proof can only base on prior
knowledge and there is no real knowledge that can be counted as proven. So
people who claim something was a proven fact must be wrong with that claim
even if the fact is correct.

There are, in fact, no human beings who are perfect, and don't
make mistakes.

True, even if they claim it was a proven fact. Once it was a proven fact
that the earth is flat.

An effectively managed team can reduces these
significantly, however, because the mistakes of one person will
be caught and corrected by another.

That is true as well, but it does not prove your claim that single
programmers could never produce good code. Their chances are lower than
those of a well managed highly skilled team.

That's true, but only in a negative sense. (There are people
who are totally incompetent at all three.) No one can shine in
all possible areas, however.

These are only three areas and at least one of them only partly. In a team
project management includes a lot of communication skills. For developers
working alone that part is not necessary. That developer doesn't need to be
equally good with rowing, writing poems, driving cars or whatever.

Even if you have not yet met any of that rare kind that are competent in all
three areas, be sure they do exist.

Having some one else review our work catches
most of those mistakes

At least that raises the probability. Again that doesn't prove that there
can not be anyone that is equally competent (in a positive sense) in project
management, software architecture and coding.

Christof

 

[Christof Donat]

Hi,

Which is a good argument for pair programming!

That is _the_ reason for pair programming. Pair programming is a very good
idea, because it really lowers the probability for mistakes a lot.

Christof

 

[Ian Collins]

Christof Donat wrote:

Please don't snip attributions!

That is _the_ reason for pair programming.

Only one of many.

 

[Andrew Tomazos]

And of course, you won't tell us what it was, or give us any
other means of verifying your claims.  (Windows NT also won some
awards, and a number of people liked it, but it's hardly what I
would call good software.)

I don't think you really believe I'm lieing about what I say.
You've just dug yourself a trench and now are stubbornly laying in it.

It has been known for some time that the world is flat, too.
Actual measurements, of course, have proven the opposite, but
that doesn't bother some people.

It's based on empirical evidence. I've seen the phenomenon firsthand,
numerous other people have given me firsthand accounts, I've read
about it in books. The only reason I can guess that you have not seen
it too, is that maybe you've never worked closely with a really good
programmer. Maybe you've been working in IT departments of nontech
sectors like banking etc. Most good programmers are cherry picked
away by the pure tech companies.
-Andrew.

 

[James Kanze]

I don't think you really believe I'm lieing about what I
say. You've just dug yourself a trench and now are stubbornly
laying in it.

It's based on empirical evidence.

The empirical evidence goes the other way. There are no good
programs developed by just a single person. You've said there's
one, but since you've refused to actually exhibit it, we have to
conclude that it's probably not as good as you think.

I've seen the phenomenon firsthand, numerous other people have
given me firsthand accounts, I've read about it in books. The
only reason I can guess that you have not seen it too, is that
maybe you've never worked closely with a really good
programmer.

I've worked with some of the best, at times. The only reason I
can guess that you think you've seen it is that you don't know
what a good program is, so you accept some just as acceptable.

Maybe you've been working in IT departments of nontech sectors
like banking etc. Most good programmers are cherry picked
away by the pure tech companies.

A lot you know---the banks are generally the ones who do the
cherry picking. But I've worked a lot on critical systems,
where quality was essential. I've also worked with the C++
standards committee, where I've had the privilege of
collaborating with some real experts.

 

[James Kanze]

Which is a good argument for pair programming!

Well, pair programming is certainly better than working in
isolation. But other organizations work too, and are usually
more cost effective. (IMHO, pair programming doesn't remove the
necessity of doing good code review, because both of the
programmers are involved with the actual writing. To get the
most advantage, you really need an outside view---someone who
has no idea about the code before hand. And once you do that,
pair programming adds very little, while requiring twice the
number of people.)

 

[James Kanze]

[...]

True, even if they claim it was a proven fact. Once it was a
proven fact that the earth is flat.

When? The basic principles of scientific proof are a product of
the renaissance, where as it's been well known in scientific
circles that the world is round since at least Ptolomic times.

That is true as well, but it does not prove your claim that
single programmers could never produce good code. Their
chances are lower than those of a well managed highly skilled
team.

Well, I suppose that a million monkeys typing away at a keyboard
could also produce a "good" program, just by chance. The
probability of it, however, is low enough that it can be
considered zero.

These are only three areas and at least one of them only
partly. In a team project management includes a lot of
communication skills. For developers working alone that part
is not necessary. That developer doesn't need to be equally
good with rowing, writing poems, driving cars or whatever.

Even if you have not yet met any of that rare kind that are
competent in all three areas, be sure they do exist.

More or less competent, perhaps, but they'll still be better in
one than the others. Software development requires both right
brain people and left brain people, and one person can't be
both.

But as I said, that's not the point. The point is that
regardless of competence, the person is a fallible human being.
Having someone else verify there work is an absolute necessity.

(FWIW: take a look at any quality technical book. The author
will not fail to cite a number of reviewers, and others who've
help in the writing.)

At least that raises the probability.

From basically zero.

Again that doesn't prove
that there can not be anyone that is equally competent (in a
positive sense) in project management, software architecture
and coding.

But that's irrelevant to the argument.

 

[Andrew Tomazos]

A lot you know---the banks are generally the ones who do the
cherry picking.

Hilarious. Most good programmers get the gag reflex at the thought of
working for a bank. So I was right. You haven't worked with any good
programmers. Just the tie-wearing IT pro crowd.
-Andrew.

 

[Stefan Ram]

There are no good programs developed by just a single person.

Do you deem »TeX« to be developed by just a single person?
Do you deem »TeX« to be »good«?

Recently, Viktor Mayer-Schönberger went public claiming that
too much »groupthink« might hinder creativity and that
programmers sometimes might need some solitude.

http://www.livescience.com/technology/etc/090724-internet-groupthink-throttles-creativity.html
http://inventorspot.com/articles/does_social_media_produce_groupthink_30660

Groups might encourage incremental improvements of classic
ideas, but might discourage individuals with radical new ideas.

Viktor Mayer-Schönberger in German:

http://www.heise.de/bin/tp/issue/r4/dl-artikel2.cgi?artikelnr=30791&mode=print

 

[Christof Donat]

Hi,

When? The basic principles of scientific proof are a product of
the renaissance,

No. People like Roger Bacon an William of Ockham were before. Aristoteles
was earlier as well. The foundations are really old.

What I actually wanted to say is that you should be careful with claiming
"proven facts".

Well, I suppose that a million monkeys typing away at a keyboard
could also produce a "good" program, just by chance. The
probability of it, however, is low enough that it can be
considered zero.

I see, you don't want to accept the fact, that there are a few people that
really are able to create high quality software alone.

More or less competent, perhaps, but they'll still be better in
one than the others. Software development requires both right
brain people and left brain people, and one person can't be
both.

It cant be because it shall not be. Reality has some surprises for all who
think they can put it into simple boxes. "Right Brain" and "Left Brain"
people are very simple boxes. Most people might fit into somehow, but there
still are some that don't fit in any of your boxes.

From basically zero.

No.

Actually I have written up to medium sized programs alone which I still
think are well designed and coded and I finished them in time, so the project
management wasn't so bad as well. I have worked as a coder, a software
architect and as a project manager and succeeded in all three areas. I have
also had various mixed roles and managed to do those jobs good as well.

I can tell you from my experience, that
1. people exist that are able to do all those three jobs well,
2. well managed a good team has a higher probability to prevent errors and
get things done and
3. single people can produce well designed good written code in a reasonable
project schedule as well. It's harder, but far from impossible.

Christof

 

[Ian Collins]

Well, pair programming is certainly better than working in
isolation. But other organizations work too, and are usually
more cost effective. (IMHO, pair programming doesn't remove the
necessity of doing good code review, because both of the
programmers are involved with the actual writing. To get the
most advantage, you really need an outside view---someone who
has no idea about the code before hand. And once you do that,
pair programming adds very little, while requiring twice the
number of people.)

You keep claiming that never having tried it.

 

[fft1976]

I don't think a professional programmer can succeed without good
management, regardless of how good he is.

This confirms my suspicion that you've never worked with anyone good.
(Being good is somewhat different than being a language lawyer, by the
way)

 

[James Kanze]

Hilarious. Most good programmers get the gag reflex at the
thought of working for a bank. So I was right. You haven't
worked with any good programmers. Just the tie-wearing IT pro
crowd.

I think you've proved my point. You obviously don't know beans
about good programs, or good programmers (or banks, for that
matter).