[OT] dealing with lower level programmers

[James Kanze]

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

No, and fundamentally, no.

It's certainly not the work of a single programmer, working in
isolation---Knuth is known for his communcations skills, and was
a thesis advisor for a number of people when TeX was being
written. (I read somewhere that a large percentage of TeX was
actually coded by one of the people who had him as a thesis
advisor. Having actually read several chapters of the source
code, however, I have my doubts---the style is definitely
Knuth's. On the other hand, Addison-Wesley published it as a
book, and technical books published by Addison-Wesley are NOT
produced in isolation---they're reviewed. And such reviews do
result in significant changes, and a lot of errors being
caught.)

As for the quality, it is significantly better than a lot of
commercial programs around. But it still contained more errors
than would have been acceptable in most places where I've
worked.

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

Even without reading the article... Any creative thinker
certainly needs moments of solitude---a lot of my best ideas
come either in the shower, or when I'm driving, with no one else
in the car. But such creative ideas, and their implementation,
do need to be reviewed.

I think it also depends on the person. I'm most creative in an
isolated context, but I've worked with people who couldn't
create unless they were doing so out loud, to a listening
audience. So that after a fairly short brainstorming session,
I'd want to break it off, so that I could think creatively about
the points raised, but my collegue wanted it to continue, for
the same reason.

 

[James Kanze]

Yes.

I'm pretty sure that's not the case, at least not in the sense I
mean. (I can't imagine that Knuth published the code without
having someone review it first. Review before publishing is a
basic principle in scholastic circles.)

No. It's a horrible programming language. Which is why it's
usually papered over with LaTeX, which masks many of its
quirks, but adds quirks of its own.

Good point. To answer the question, you have to precise what is
meant by "good". With regards to the number of errors, it's
better than a lot of commercial software, but still not what
would be considered "acceptable" in many places I've worked.
With regards to the quality of the output, I don't know of
anything better; I'm a bit of a perfectionists, and I use LaTeX
because the output is so beautiful (compared to, say, Word).
With regards to the "language", on the other hand... it is just
attrocious; it makes Fortran IV look elegant. (I suppose one
could argue that as TeX itself was really meant to be used as a
sort of "assembler" in which to write higher level languages,
it's acceptable. Except that plain TeX was supposed to be one
of those higher level languages, and neither it nor LaTeX---the
most widely used of the higher level languages---are really much
better.)

 

[James Kanze]

You keep claiming that never having tried it.

There are lot's of things I've never tried. That doesn't mean I
can't analyse, and make some prognostics. The people who
propose it never point to any studies where it was compared with
more established techniques, like code review, which have been
proven effective in many environments. As I said, it is
certainly a significant improvement over programming in total
isolation. But better (more cost effective) techniques are
known.

 

[James Kanze]

No. People like Roger Bacon and William of Ockham were before.

I'd consider them precursers of the renaissance. And I'm not
sure they really covered everything we understand in "scientific
proof" today.

Aristoteles was earlier as well. The foundations are really
old.

Some of the foundations, yes. But not really what we'd insist
on for scientific proof today. (Predictividy, reproduceability,
etc.)

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

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.

Because I don't accept that any human being can be perfect, and
that he can produce a significant work without errors.
Empirical evidence supports me in this: to date, no human being
has ever produces a perfect work, in any field. And they've
been trying for a long time.

It cant be because it shall not be.

Can't be because despite all of the efforts to find an
exception, none has been found. It's an empirical proof, but
given the size of the observed data, it's rather hard to deny
it.

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.

Right brain and left brain are simple boxes, and people do lie
along a continuum. But they do represent distinct skills, and
people near the middle aren't particularly gifted for one or the
other (i.e. they aren't at one of the extremes).

No.

So you're arguing that some human beings are infallible.

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.

But you're missing the main point. They're still fallible, and
need someone else to review their work.

I can tell you from my experience, that
1. people exist that are able to do all those three jobs well,

For a low enough level of well, I suppose.

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.

A person, working alone, will still make significant errors
which would be caught by a review by a third party.

 

[James Kanze]

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)

So show an exception. Empirical evidence supports my
statement---where management is bad, projects fail, regardless
of how good the programmers on them are. To date, no one has
been able to present an exception, and an awfully large data set
has been examined.

 

[Christof Donat]

Hi,

I'd consider them precursers of the renaissance. And I'm not
sure they really covered everything we understand in "scientific
proof" today.

As a modern mathematically educated man I can not accept as a proof what you
tell us.

You claim, that A can never happen and try to proof that with saying: "I
have never seen A happen." People come up who claim that they have seen A
happen. They must be wrong and people who claim they have even made A happen
must be liars. The simple fact is, that your proof is invalid as a proof.

Because I don't accept that any human being can be perfect,

That automatically leads to the conclusion that any group of human beings
can never be perfect. Just maybe closer to perfect than a single human that
is part of the group. There is nothing more in what I said. You will never
get perfect software which is notably more complex than "hello world". No
matter how many people you have in your team.

and that he can produce a significant work without errors.

Oh yes, he can. Maybe you can't. Maybe you never met anyone who can. But
these guys are out there. Don't ask them to do their laundry or cook a meal
- they won't be able to accomplish tasks like that, but there are people
that can produce significant pieces of software alone.

Empirical evidence supports me in this: to date, no human being
has ever produces a perfect work, in any field. And they've
been trying for a long time.

Some have come quite close.

Has any group of people ever produced a perfect work? If so show me.

Can't be because despite all of the efforts to find an
exception, none has been found.

You haven't found => none has been found.

given the size of the observed data,

Tell us what data you have observed. Obviously there are people around here
that have observed other data.

Right brain and left brain are simple boxes, and people do lie
along a continuum.

No, reality is not linear. Here we see another too simple box to fit reality
into it.

So you're arguing that some human beings are infallible.

No, but you argue, that there is a group of people that is infallible.

But you're missing the main point. They're still fallible, and
need someone else to review their work.

Show me the perfect software that has been produced by a group of people. If
there is none, show me the perfect piece of work that has been done by a
group of people.

You will never get perfection.

Christof

 

[Noah Roberts]

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.

LOL!!!

"I'm right and you can't see that because you suck!"

"No. I'm right and you can't see that because you suck!"

"Actually, the only reason you think that is that you suck!"

"Well, if you didn't suck you'd know that you're clearly mistaken!"

How long you guys intend to keep THAT up? You, Mr. Kanze, seem prone to
this kind of argument. If you can't convince them with absolutisms and
other nonsense, tell them they suck.

NEITHER of you are arguing from an empirical point. There is no such
thing as objectively decidable "good software". To be empirical there
must be a measurable gradient by which to judge. Neither of you has
provided one. After reading the back and forth it seems clear to me
that the definition Mr. Kanze is working with is, "anything not created
by a solo developer," because no amount of examples of people who've
considered solo development projects "good" seems to knock him from his
high horse or pull that gigantic brush from his hand.

People can disagree with you. It's not the end of the world. There's
absolutely no way that, "...it's a proven fact," that solo developers
can't create something good because nobody agrees what constitutes
"good" in the software industry. Ask one industry expert and you'll get
an entirely different answer from the next one. Neither is wrong.

Anyway, I'll leave you to this undecidable argument. If you keep
insisting how much better you are than each other one of you might cave,
but I seriously doubt it. Argument from authority is even less
convincing when you declare yourself the authority.

 

[James Kanze]

"I'm right and you can't see that because you suck!"

"No. I'm right and you can't see that because you suck!"

"Actually, the only reason you think that is that you suck!"

"Well, if you didn't suck you'd know that you're clearly mistaken!"

How long you guys intend to keep THAT up? You, Mr. Kanze,
seem prone to this kind of argument. If you can't convince
them with absolutisms and other nonsense, tell them they suck.

NEITHER of you are arguing from an empirical point.

There's a large body of empirical evidence which proves that
human beings are fallible. And that there is no 100x factor
between the best and the worst. There's also a lot of programs
out there that one can look at, and discuss.

There is no such thing as objectively decidable "good
software".

There are established measures for some aspects, like the
absense of errors. For others, no.

To be empirical there must be a measurable gradient by which
to judge. Neither of you has provided one. After reading the
back and forth it seems clear to me that the definition Mr.
Kanze is working with is, "anything not created by a solo
developer," because no amount of examples of people who've
considered solo development projects "good" seems to knock him
from his high horse or pull that gigantic brush from his hand.

If you choose to ignore the data, there's not much I can say.
(Andrew has no exposed his data---he just says it exists, but we
can't see it.)

People can disagree with you. It's not the end of the world.
There's absolutely no way that, "...it's a proven fact," that
solo developers can't create something good because nobody
agrees what constitutes "good" in the software industry.

Again, that's only true for some aspects of "good". Anything
with more than about 1 error per 100 KLoc of code is certainly
not good. (That doesn't mean that it's not usable.) So I
submit the challenge: show me a program which was written by a
single person, without any help (no reviews, etc.), which has
only 1 error per 100 KLoc of code or less. That's what it would
take to convince me.

 

[Andrew Tomazos]

And that there is no 100x factor between the best and the worst.

Actually the 100x figure is between the best and the average. The
worst programmers actually do damage to a project, so their
productivity is negative.
-Andrew.

 

[Andrew Tomazos]

NEITHER of you are arguing from an empirical point.  There is no such
thing as objectively decidable "good software".

My definition of good software, is software that has an intuitive
interface and the implementation does what you expect it to. Human
expectations and intuitions vary, so when we speak about these
qualities in general, we are talking about "most users". So let me
propose a question:

"If every user that this software is designed for, were to use it in
every possible situation that they would do - would the overwhelming
majority of them (a) consider it easy-to-use; and (b) find that it
operated as they expect?"

If the answer is yes, than it is good software.

In order to test empirically, one could take a random sample of
intended users, get them to thoroughly use the software, and then ask
them whether they found it intuitive and if it worked as expected.

So there you go, "good software" measured empirically.

Furthermore, the idea of counting errors per line of code is
preposterous. Some issues are clearly bugs (the program freezes) or
feature requests (the icon should be blue) - but most issues fall
somewhere on a continuous scale in between. To compound the problem
many issues can be thought of as one singular issue, or alternatively
as a set of multiple issues. Further, depending on your perspective
you can be looking at issue causes or issue symptoms which form a
graph in which there is interrelation and not necessarily one-to-one
correspondences.

You usually get into this idea of counting errors, when you have an
unmotivated permanent development team, and are trying to compensate
for that with formal process. It never works, and just wastes time.
-Andrew.

 

[Pascal J. Bourguignon]

My definition of good software, is software that has an intuitive
interface and the implementation does what you expect it to. Human
expectations and intuitions vary, so when we speak about these
qualities in general, we are talking about "most users". So let me
propose a question:

"If every user that this software is designed for, were to use it in
every possible situation that they would do - would the overwhelming
majority of them (a) consider it easy-to-use; and (b) find that it
operated as they expect?"

If the answer is yes, than it is good software.

In order to test empirically, one could take a random sample of
intended users, get them to thoroughly use the software, and then ask
them whether they found it intuitive and if it worked as expected.

So there you go, "good software" measured empirically.

Furthermore, the idea of counting errors per line of code is
preposterous. Some issues are clearly bugs (the program freezes) or
feature requests (the icon should be blue) - but most issues fall
somewhere on a continuous scale in between. To compound the problem
many issues can be thought of as one singular issue, or alternatively
as a set of multiple issues. Further, depending on your perspective
you can be looking at issue causes or issue symptoms which form a
graph in which there is interrelation and not necessarily one-to-one
correspondences.

You usually get into this idea of counting errors, when you have an
unmotivated permanent development team, and are trying to compensate
for that with formal process. It never works, and just wastes time.

Not to mention that half of the bugs I see actually are not errors in
the program, but things that were not specified formally and which
once implemented suscite a different "specification". The other half
being mostly problems with using underspecified / documented libraries.

Programmer errors are actually rather rare because either the program
won't compile, or won't run, or won't pass the minimal unit tests.
That is, they're as much "bugs" as the typos you can make while
editing the program. If you increment your bug corrected counter
every time you press the DEL key, then ok, solo programmers produce a
lot of bugs.

 

[James Kanze]

Furthermore, the idea of counting errors per line of code is
preposterous.

That's why it's one of the principal measures used in places
where critical software is written. When the software has to
work, then you take the necessary steps.

[...]

You usually get into this idea of counting errors, when you
have an unmotivated permanent development team, and are trying
to compensate for that with formal process. It never works,
and just wastes time.

Without some sort of process, you don't know whether your
software is doing what it is supposed to do, or how good you
really are. Noah was very right about one thing: you have to
measure.

 

[Noah Roberts]

My definition of good software, is software that has an intuitive
interface and the implementation does what you expect it to. Human
expectations and intuitions vary, so when we speak about these
qualities in general, we are talking about "most users". So let me
propose a question:

"If every user that this software is designed for, were to use it in
every possible situation that they would do - would the overwhelming
majority of them (a) consider it easy-to-use; and (b) find that it
operated as they expect?"

If the answer is yes, than it is good software.

In order to test empirically, one could take a random sample of
intended users, get them to thoroughly use the software, and then ask
them whether they found it intuitive and if it worked as expected.

So there you go, "good software" measured empirically.

Problem is that I don't agree with your definition. Although we can
certainly say that the program doing what is intended and being easy to
use is a necessary component of "good software", I would consider that
more an aspect of interface design and that's only one side of the coin.
The other side of the coin, when the user likes it so much that they
start suggesting changes...can they be made easily? THAT I think is if
not the most important aspect of "good software" then it's the second
most important aspect.

Furthermore, the idea of counting errors per line of code is
preposterous.

I agree. Any metric that depends on LOC count is a questionable metric
at best. I also don't think this would be a good measure of "good
software". You can write completely shitty code but it will be bug free
and follow specification...you'll just end up completely rewriting it
for every simple change and/or spend 10x+ as long as you would have with
"good software".

We should also consider the fact that whatever "good software" is there
must be a continuous scale, not a discrete one. We can't draw a line
somewhere and say good is on one side and bad on the other. There are
degrees of crappiness when it comes to software. A solo developer can
write software that will fall on that scale on one side or the other of
a line we cannot draw...for some people and not for others. A solo
developer can write software that is much "gooder" than software made by
some teams.

 

[Noah Roberts]

There's a large body of empirical evidence which proves that
human beings are fallible.

So are teams of humans. In fact, there's a large body of empirical
evidence that shows groups of humans act even stupider than solo human
in many cases and fall prey to a whole set of new problems; group think
is but one example.

And that there is no 100x factor

between the best and the worst. There's also a lot of programs
out there that one can look at, and discuss.


There are established measures for some aspects, like the
absense of errors. For others, no.

And that's a completely arbitrary definition that leaves out many areas
for crapiness.

If you choose to ignore the data, there's not much I can say.
(Andrew has no exposed his data---he just says it exists, but we
can't see it.)

Same goes for you. Show me evidence that the majority of software teams
can produce code that has <1 error per 100 kloc and that no solo human
being is capable of the same. Show me evidence that these teams are
still efficient at producing products and innovate with new ideas and
directions (problem being that too much concern over error tends to
stamp down risk taking). How long does it take said team to produce 100
kloc? What constitutes an error? Spelling mistakes in the interface?
How many people are on these teams?

If the average person can develop 50 error free loc in a day then it
would take 5.5 man years (including weekends/holidays) to develop those
100kloc of error free code you're looking at. 100kloc is a small
program. It seems to me that you're again being completely arbitrary
and setting up the conversation to run in your favor without providing
any evidence that we should accept your definition.

 

[Noah Roberts]

Because I don't accept that any human being can be perfect, and
that he can produce a significant work without errors.
Empirical evidence supports me in this: to date, no human being
has ever produces a perfect work, in any field. And they've
been trying for a long time.

But you haven't told us why "good software" must be "perfect software".
From my perspective it doesn't require a perfect human to develop
_good_ software..convenient thing too because otherwise there'd be no
such thing as good software, written by teams or otherwise.

 

[Noah Roberts]

That automatically leads to the conclusion that any group of human beings
can never be perfect. Just maybe closer to perfect than a single human that
is part of the group.

Or visa-versa. A human alone has X number of flaws. A group of humans
has XN number of flaws and often times the X's complement each other to
create new flaws so you have XN + Z number of flaws such that for any n
in the group the non-flaws about that person cannot possibly counter the
flaws in the entire group.

 

[Ian Collins]

Without some sort of process, you don't know whether your
software is doing what it is supposed to do, or how good you
really are. Noah was very right about one thing: you have to
measure.

Ah, but measure what?

I've always judged my my code by either customer satisfaction and (lack
of!) support revenue with a single customer or field defects for
applications with many, unknown, customers.

 

[fft1976]

So show an exception.  Empirical evidence supports my
statement---where management is bad, projects fail, regardless
of how good the programmers on them are.  To date, no one has
been able to present an exception, and an awfully large data set
has been examined.

That's not what you said, actually. "Without management" and "with bad
management" are different things.

 

[Noah Roberts]

Noah was very right about one thing: you have to
measure.

Actually, what I said was that in order for something to be empirically
based there must have been a measurement done.

I don't agree with you that software "goodness" is something that can be
measured. In fact, I can't think of any "goodness" that is possible to
measure. Various things that various people think are "good", sure, but
"goodness" is a subjective term that can't be empirically measured or
applied.

For example, you are using "goodness" to mean, "lack of errors." We can
measure errors, somewhat, but since not everyone agrees with your use of
the term "good" we haven't objectively measured "goodness". This is why
when speaking empirically it is best to use objective terms like "lack
of error" instead of "goodness". Then people know WTF you're talking about.

 

[Ian Collins]

Actually, what I said was that in order for something to be empirically
based there must have been a measurement done.

I don't agree with you that software "goodness" is something that can be
measured. In fact, I can't think of any "goodness" that is possible to
measure. Various things that various people think are "good", sure, but
"goodness" is a subjective term that can't be empirically measured or
applied.

For example, you are using "goodness" to mean, "lack of errors." We can
measure errors, somewhat, but since not everyone agrees with your use of
the term "good" we haven't objectively measured "goodness". This is why
when speaking empirically it is best to use objective terms like "lack
of error" instead of "goodness". Then people know WTF you're talking
about.

Could it be that we are looking at quality or "goodness" from different
perspectives?

My perspective is that of a business supplying a product (which happens
to be code) to a customer. From that perspective I don't really care
how many lines of code there are. I care about customer satisfaction
and my bottom line. Sure I strive for perfection, but that has to be
balanced with cost and delivery dates. "Good" code is code makes my
customers happy, generates follow up work and doesn't cost me time in
bug fixes (I don't charge for those).

My customers are happy and I haven't gone bust, so therefore I must be
producing good code!