[OT] dealing with lower level programmers

[James Kanze]

[...]

Alone too.

Group work is not a guarantee of implementing code reviews.

Working along is a guarantee that they aren't implemented,
however.

Basically, you can do code reviews alone, by just forgetting
your code, and then reviewing it.

I do that too, when I have to work alone. It's still far from
being as effective as having other people do the review.

There's also all of the ad hoc discussions that occur (or should
occur) when you're working in a team. You discuss what you're
doing with someone else at the coffee machine, and he points out
a potential problem. That you then fix, before formel review.

AFAICSITRL, this is completely wrong. Team programming leads
to huge quasi unmaintenable, bug-ridden programs that nobody
can understand completely, and that work only by miracle (and
thanks to encapsulation).

No doubt that's why all of the companies implementing critical
systems insist on team programming, and why it is required in
such cases.

Mostly, where there's something wrong in a program by one, the
one will pause and correct the wrong thing. When there's
something wrong in a program by many, there is a lot of red
tape, and group psychology to overcome before being able to
correct it. In practice most problems in team programs never
get corrected, just wrapped over as far as there's a customer
crying for a bug correction.

That's just bullshit. Mostly, programmers are human beings, and
as such, imperfect. They all make mistakes. And they don't see
their own mistakes---that takes someone else.

This is obviously wrong, there are several example.

Such as?

What may be true is that the scope and size of a program
written by an individual might be smaller, but how would that
be a bad thing? At least an individual will produce programs
that are understandable and manageable.

"Mythical Man Month".

Irrelevant here. You're not adding additional people (beyond
the optimal) in the middle of a project, to hopefully make the
project go faster.

 

[James Kanze]

On Jul 17, 4:35 am, (e-mail address removed) (Pascal J. Bourguignon)
wrote:

[...]

It may help to recall how Noah and his three sons built the
ark. In that case a single family worked out their salvation
while others were lost to the flood. That family was able to
produce a vessel capable of saving both them and a bunch of
animals including some birds that eventually helped them find
land.

That family wasn't a single individual. And in the version I
heard, they had some significant outside help, especially with
regards to design and management.

 

[James Kanze]

* James Kanze:

Donald Knuth: LeX.

That's probably the closest, but don't forget that he was a
professor, and supervised a number of doctorat theses. I don't
think that anyone in accademia really can be said to be working
alone. (I seem to recall reading somewhere that in fact,
something like 80% of TeX was actually coded by one of his grad
students. I can't find the reference, and I'm not really 100%
sure, but it certainly sounds likely, based on what little I
know of accademia.)

Most teams, of course, don't have anyone nearly that skilled,
and most projects today are significantly larger, as well, so
even if he did do it alone, that would be the exception that
confirms the rule. But if it makes you happier, I'm willing to
modify my statement to the effect that "a single individual is
incapable of writing a correct program, unless he is at least as
skilled as Donald Knuth." I still think my original wording is
more exact, but since I don't have any concrete experience
working with people as skilled as Knuth, I can't be 100% sure.

As I understand it and vaguely recall it was an interesting
exercise in "literate programming", a kind of far more
sophisticated and powerful version of today's doc comments
(like //@), with the code just part of the documentation.

A far more sophisticated and powerful version, yes. One which
starts from the correct philosophy: you write the documentation
first, and extract the code from it, rather than vice versa.

However I've never seen the code.

I have.

The real problem is that it is still "source code". TeX source
code, rather than Pascal source code, but the TeX markup is
there, embedded in the document. It's still an order of
magnitude better than most other things I've seen (since the
markup isn't that invasive), and later adaptations seem to have
improved it even more, but you're still writing to be read at
two levels: a generated document (where the markup handles
sectionning and other details) and the actual document the
maintenance programmer sees (which contains markup, and whose
formatting depends on what you've entered directly, e.g. spaces,
new lines, etc.).

 

[James Kanze]

A lot of Open Source software are the work of single men,
even if later the original authors are able to aggregate
contributors. But notice that then, all the work is done
remotely, with absolutely no "management".

Which explains why so much of it is total junk. There are a few
exceptions, like g++, but 1) they do have some sort of
management, and 2) they're only "good" compared with the
commercial equivalents, which often don't have any decent
management either.

 

[Ian Collins]

James Kanze wrote:

[...]

I don't get that. I've worked for clients on the other side of
the world and we'd both say that they had no trouble managing
me (not that they had to) and that I performed well.
Were you working alone, or in a group?

Alone.

If alone, how did you do code reviews, or brainstorming
sessions.

Acceptance testing and any reviews where done by the clients.

I would take that as a given. But if I were a client, the code
would either pass or fail the review, and if it failed, you
won't be paid. As a client, the reason I pay is to not have to
do all of the work.

The code either pass or fails the tests.

Testing can never prove correction; it can only prove that the
code is incorrect.

Correctness is in the eye of the beholder, in my case that's the client.

Certainly. And programmer--management communication as well.
Generally, the client--implementer communication will be
somewhat structured, but the programmer--programmer, and to a
degree, the programmer--management, communication entails a
significant amount of impromptu communication (as well as some
structured communication).

So should client - programmer. This is more typical and important when
there is a single client and a single implementer.

 

[James Kanze]

James Kanze wrote:
James Kanze wrote:

[...]
I would take that as a given. But if I were a client, the
code would either pass or fail the review, and if it failed,
you won't be paid. As a client, the reason I pay is to not
have to do all of the work.

The code either pass or fails the tests.

Since you'll be writing the tests, that won't help me much. And
I want the code not only to work, but to be maintainable.

Correctness is in the eye of the beholder, in my case that's
the client.

Yes, and no professionally competent organization will accept
code just because it passes some arbitrary set of tests. It has
to be maintainable.

So should client - programmer. This is more typical and
important when there is a single client and a single
implementer.

In such cases, one could argue that the development isn't just
the implementer; that the implementer is in fact part of my in
house team. In such cases, impromtu communication is important;
that's why I always work on the customer site. I tried once
working at a distance, but quickly found that I was "out of the
loop".

Also, I don't pretend to fournish finished software in such
cases. I'm part of the customer's team (except for tax and
labor law purposes).

 

[Keith H Duggar]

Here's an example: suppose my spec says "write a program which is valid
C++ but does absolutely nothing". My implementation looks like:

int main()
{
return 0;

}

That's a correct program (although I look forward to somebody
challenging that assertion ) which meets its specification. I'm a
single individual, and I wrote it. Surely that makes the statement above
false? We can change the terms of debate to "correct *non-trivial*
program" if you like

I think those are already the terms of an adult debate. In other
words this isn't 1st grade playground my dad can kick your dad's
ass a million gazillion times banter. So you might have known or
at least assumed upfront that James didn't mean nonsense trivial
"look what I can do" programs.

So, it would be nice to explore real world examples. Knuth's TeX
was brought up as a counter example. However, people other than
Knuth found and reported (to Knuth) bugs in TeX. So I don't know
if TeX falls under James' definition of "correct" or not, and if
that 3rd party testing breaks "single individual" or not.

KHD

 

[Ian Collins]

James Kanze wrote:
James Kanze wrote:
[...]
I would take that as a given. But if I were a client, the
code would either pass or fail the review, and if it failed,
you won't be paid. As a client, the reason I pay is to not
have to do all of the work.

The code either pass or fails the tests.

Since you'll be writing the tests, that won't help me much. And
I want the code not only to work, but to be maintainable.

The code either pass or fails the customer's tests.

Yes, and no professionally competent organization will accept
code just because it passes some arbitrary set of tests. It has
to be maintainable.

Then there's a lot of professionally competent organisations out there!

In my case, I'm the one paid to maintain the code. They pay for
additions, I pay for bug fixing. Which gives me the incentive to
deliver what they want and make sure they test it.

 

[Brian Wood]

On Jul 17, 4:35 am, (e-mail address removed) (Pascal J. Bourguignon)
wrote:

    [...]

It may help to recall how Noah and his three sons built the
ark.  In that case a single family worked out their salvation
while others were lost to the flood.  That family was able to
produce a vessel capable of saving both them and a bunch of
animals including some birds that eventually helped them find
land.

That family wasn't a single individual.  And in the version I
heard, they had some significant outside help, especially with
regards to design and management.

There were four men and they each had a wife. They had as you
say a lot of "outside help". Anyway, I bring it up as an
example of a large, successful project that involved a small
number of people. I am not arguing against what you wrote,
but saying there's no reason to be afraid of joining a small
team that has a big project in front of them.


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

 

[James Kanze]

On Jul 17, 4:35 am, (e-mail address removed) (Pascal J. Bourguignon)
wrote:

[...]

a single individual is incapable of writing a correct
program, regardless of how skilled he is.
It may help to recall how Noah and his three sons built
the ark. In that case a single family worked out their
salvation while others were lost to the flood. That
family was able to produce a vessel capable of saving both
them and a bunch of animals including some birds that
eventually helped them find land.

That family wasn't a single individual. And in the version
I heard, they had some significant outside help, especially
with regards to design and management.

There were four men and they each had a wife. They had as you
say a lot of "outside help".

Of a sort most software projects can't hope for. (Most software
projects can't even hope for someone as skilled as Knuth, much
less an omniscient, infallible design specialist.)

Anyway, I bring it up as an example of a large, successful
project that involved a small number of people. I am not
arguing against what you wrote, but saying there's no reason
to be afraid of joining a small team that has a big project in
front of them.

I've never said anything against small teams. In fact, it's
generally easier to establish the necessary communication in a
small team. The ideal size of the team will vary, depending on
the size and complexity of the project, and the desired delay.
Optimizing for cost will *NOT* generally result in the shortest
delay, but you will run up against a limit fairly soon when
trying to shorten the delay which results in lowest cost.

 

[James Kanze]

So, it would be nice to explore real world examples. Knuth's
TeX was brought up as a counter example. However, people
other than Knuth found and reported (to Knuth) bugs in TeX. So
I don't know if TeX falls under James' definition of "correct"
or not, and if that 3rd party testing breaks "single
individual" or not.

The real question is: what do we mean by "correct"? There's a
very real sense that my statement is trivially correct: no
non-trivial program can be guaranteed 100% correct (without any
bugs), so obviously, no non-trivial program written by a single
person can be 100% correct. That's just game playing, like
Stuarts example of a program which does nothing, but the
question remains: how many bugs to we accept? And do we take
into consideration maintainability issues: how difficult is it
to correct the bugs once they are found? (With regards to TeX,
at least seven bugs have been found and fixed since version 3.0
was released. The source is around 40KLOC, so that's not a
particularly low bug rate.)

What I'd really be interesting in seeing is a real life example
of a real program written by a single person which is considered
correct, with a statement as to what is considered correct or
how it is known to be correct.

 

[Gerhard Fiedler]

I don't buy that. It's possible that he can't get the required staff
at his place of work, but that's a budgeting or an administrative
problem, not linked to place---he won't be able to hire a good
programmer regardless of where he finds him: locally or somewhere
else.

There's always an option, and everything is a trade-off...

Not everybody is in a metropolis, or in a densely populated, highly
developed area. It seems to be obvious that for any given specific skill
there are many places where it can't be found locally; not sure why
anybody would want to debate this. The cost of convincing someone with
the skill to move to where the skill is needed may be prohibitive.

This regularly puts people in the situation of having to decide between
a local, lesser qualified (for a particular job or situation) person and
a remote but better qualified person, and of having to calculate the
trade-off between the advantages of the immediate communication physical
presence brings and the advantages proper qualification (for this
particular job or situation) brings. This trade-off doesn't always swing
towards the immediate communication.

Gerhard

 

[Brian Wood]

On Jul 17, 4:35 am, (e-mail address removed) (Pascal J. Bourguignon)
wrote:
    [...]
a single individual is incapable of writing a correct
program, regardless of how skilled he is.
It may help to recall how Noah and his three sons built
the ark.  In that case a single family worked out their
salvation while others were lost to the flood.  That
family was able to produce a vessel capable of saving both
them and a bunch of animals including some birds that
eventually helped them find land.
That family wasn't a single individual.  And in the version
I heard, they had some significant outside help, especially
with regards to design and management.

There were four men and they each had a wife.  They had as you
say a lot of "outside help".

Of a sort most software projects can't hope for.  (Most software
projects can't even hope for someone as skilled as Knuth, much
less an omniscient, infallible design specialist.)

I disagree. G-d wants to help people and still does so.
More recently, there's David and Goliath. David killed
Goliath even though Goliath was more experienced and
was much bigger physically than David.
If you said, most software projects don't even hope for
someone as skilled as Knuth, much less ..., I'd be more
inclined to agree. But there's something wrong with that.
How could a software project hope for anything? I'll assume
you're not playing some sort of word game.

I've never said anything against small teams.  In fact, it's
generally easier to establish the necessary communication in a
small team.  The ideal size of the team will vary, depending on
the size and complexity of the project, and the desired delay.
Optimizing for cost will *NOT* generally result in the shortest
delay, but you will run up against a limit fairly soon when
trying to shorten the delay which results in lowest cost.

Are you saying there's an organic aspect to projects that
should be considered?


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

 

[Gerhard Fiedler]

-- Clear Specs : it is essential that managers write workable and
clear specifications. Code is one of the clearest forms of
communication so provide them with skeletons of what you want such as
interfaces or algorithms where appropriate. All specs must be
written! It's good to verbally explain and discuss the specs, but
ultimately the verbal communication must denoted in written form and
communicated. Employees should take notes in technical discussions
related to work items. If necessary this fold all the way down to
pair programming.

An important aspect of "clear" specs is that they must be clear to both
parties This basically means that the level of detail depends on the
person doing the job. For some, a high-level description is good enough,
because you can trust that they either know what to do, or know when
they don't know -- and go out themselves and efficiently get that
information, as well as you could do it. For others, you need to be more
specific.

It's important to get a feel for this level. Too detailed, and people
feel micromanaged and may get demotivated. Too coarse, and people feel
(or are) lost -- and may get demotivated just the same

Ideally the level is so that the person is pround that she managed to
complete it, and what she did is so that you can say "great job!"

Gerhard

 

[Keith H Duggar]

Hey look, it's your lucky day!

Computer geeks invented something to solve your problem, it's called
"The Internet".

With "The Internet", you can send specifications to highly qualified
programmers located elsewhere, and get back good quality code along
with an invoice. You pay the invoice and you may send back
specification patches, to get program patches.

Can you please recommend a few websites or other resources that you
find most helpful for finding and utilizing quality developers over
the Internet? Thanks!

KHD

 

[Noah Roberts]

Can you please recommend a few websites or other resources that you
find most helpful for finding and utilizing quality developers over
the Internet? Thanks!

rentacoder.com

 

[Noah Roberts]

There were four men and they each had a wife. They had as you
say a lot of "outside help". Anyway, I bring it up as an
example of a large, successful project that involved a small
number of people. I am not arguing against what you wrote,
but saying there's no reason to be afraid of joining a small
team that has a big project in front of them.

A large, impossible project. I for one think fairy tale solutions to
real world problems is PART of the problem in the software industry.

I gather you believe it, and you're free to do so, but for those of us
who can't depend on miracles and a god's personal intervention (come on,
even you must admit that the lumber alone would have taken 4 people a
decade to produce) need to concentrate on methods that don't involve
divine boogiemen.

 

[Noah Roberts]

I disagree. G-d wants to help people and still does so.

Is there any conversation in which people won't attempt to prostheletize?

 

[Brian Wood]

Is there any conversation in which people won't attempt to prostheletize?

In the United States the national motto is: In G-d we trust.
I believe G-d has been and is leading me with Ebenezer
Enterprises. With many companies failing, I suggest to them
the same help I've got. He doesn't charge anything for his
help.


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net


"Unless the L-RD builds the house, they labor in vain
that build it; unless the L-RD keeps the city, the
watchman waketh but in vain." Psalm 127:1

 

[Noah Roberts]

In the United States the national motto is: In G-d we trust.

Rewriting/forgetting US history is not a valid excuse for rudely
intruding in a reasonable conversation about important issues with your
religiously led need to convert everyone to your way of thinking. You
can be happy with what one group of lawmakers decided--nearly 200 years
after the formation of the country--to be our national motto (replacing
the original) but it's completely beside the point in professional
conversations (unless of course your profession is religion).

Many of us recognize the fact that cultures go through phases and in the
1950's this country was under the influence of a religious fervor and
fear of "The Communists". A lot of mistakes were made and a lot of
"god" injected where he didn't belong.

I believe G-d has been and is leading me with Ebenezer
Enterprises.

You're free to think whatever you want. I'll definitely add you to the
list of companies to run away from should I find our paths crossing.
You may as well be sacrificing chickens at your management meetings or
following the newspaper horrorscope. I'll stick to professionals, thanks.

E pluribus unum