Re: dealing with lower level programmers
On Jul 19, 9:55 pm, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
On Jul 17, 11:18 am, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
On Jul 16, 12:26 pm, Ian Collins <ian-n...@hotmail.com> 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.
Good programming is a team effort---a single individual is
incapable of writing a correct program, regardless of how
skilled he is.
Maybe, but I've written a lot of programmes for clients
incapable of reviewing the code. "Correct" behaviour can be
determined with sufficient developer and client testing.
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.
Yes, and no professionally competent organization will accept
code just because it passes some arbitrary set of tests. It has
to be maintainable.
True, but the collaboration and communication doesn't have
to be between programmers. Programmer - client
communication is at least as important as programmer -
programmer communication.
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.
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).
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34