Re: dealing with lower level programmers
On Jul 30, 5:04 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
James Kanze wrote:
I wasn't going to respond any further here, since the argument
is really "Everyone I've ever worked with is incompetent" (from
Andrew) and "I'm just being argumentive if I dispute this" (from
Noah). As it happens, most of the people I've worked with, with
very, very few exceptions, are good programmers, the insults
thrown out gratuously by Andrew not withstanding. (And until
Noah understands this basic principle, he's not going to be able
to effectively lead a team. Leadership starts with respect for
your subordonnates.)
As for the idea that no good programmer would work at a bank:
http://bartelby.net/17/1/31.html. In fact, I've over thirty
five years of professional experience, in many different
domains: OS, compilers, embedded systems, telecoms and banks,
and there's no significant difference in the level competence
depending on the domain. (There is a difference in the fields
of competence---you'll find a lot more experts in numeric
programming working in investment banks than on embedded
systems.)
As for the +100 factor: superman only exists in comic books;
human beings just don't vary that much in their capacities.
As for the statement "one person, working alone, cannot write a
good program", it's obviously a simplification, and a bit of
hyperbole, since it doesn't mean much without a definition of
good, when applied to a program, and "working alone", for that
matter---witness the discussion about TeX. (I wouldn't consider
anyone writing reviewed works in a University context "working
alone". But the collaboration is obviously of a different
nature than that usual in enterprise, and I can understand a
difference of opinion concerning that definition.)
[...]
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.
Certainly. It's a necessary condition. It's not a sufficient
one. (Good software doesn't crash. Regardless of how good it
is in other aspects.)
It just happens to be the easiest one to measure. And one that
can't be achieved by a person working in isolation, at least as
far as I can tell. (For non-trivial software, of course.)
[...]
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.
I supposed that my data was well known to most practionners,
since it has been widely published. If not,
http://www.sei.cmu.edu/ is a good place to start.
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.
The majority of software teams probably can't. It takes at
least an SEI level 3, and I think (without looking it up, so
don't bet on it) that that's less than 10% of the organization
the SEI has measured. It takes a pretty good process to get to
that level; only one of the places I've worked has achieved it.
But it's certainly a possibility, and at least one place has
documented significantly better. My experience (and this is
very subjective) is that anything you do bringing you closer to
the 1 error per KLOC tends to reduce costs in the long run
("quality is free"); I can't really say for sure, but
intuitively, I suspect that going beyond that will quickly
become very expensive. (The organisms which do significantly
better generally have to, regardless of price.)
As for why a single person can't do this well... Well, I've
known a lot of really good programmers---some of the best, in
fact, and none come anywhere close. And given that some of
these are at the upper limits of competence, and given the
limits in variance in human performance, it seems like a very
reasonable assumption. Do you know, or have you even heard of,
anyone who even claims anything close to this. (I know my upper
limit is about 1 line per 10 KLOC, and I don't always perform at
that level.)
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).
Concern for errors does mean that you have to evaluate risks.
So does most other things. Radical experimentation belongs in
the University, not in industry. And I've never heard of a
client who pays just for something to be "new"---they want
working solutions to real problems. (And from experience---the
first program to exploit a new idea is never "good". There's a
reason it's called the "bleeding edge".)
How long does it take said team to produce 100 kloc?
It depends on how many people are in the team, and how complex
the problem domain is.
What constitutes an error?
Anything that has to be fixed.
Spelling mistakes in the interface?
Or even in the log file output, or the documentation. Anything
that causes you to have to change something in the deliverables
after delivery. (From the programmers point of view, delivery
is delivery to the integration team, at least on large
projects.)
How many people are on these teams?
It varies, but in the places I've worked, four to six people in
each group seems to be about optimal. The larger the project,
the more groups you need. Or maybe I should say, can use;
there's an upper limit to the number of groups that can be used
effectively, which varies according to the size and complexity
of the project.
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.
One person doesn't develop "error free LOC". And it's very
difficult to discuss time in the abstract, because it varies so
much. In cases where I have a rigid, fixed specification of
exactly what the program is to do, and it involves a field in
which I have expertise, I'm capable of producing about 40 KLOC
in a man year, with about 1 error per 10 KLOC. But those
conditions are very exceptional, almost never met. And that's
working alone---the results are, I think, better than most could
do, but they're still not what I would consider "good". For
that, I need help---code reviews, etc. (At the other extreme,
if the customer has no real idea what he wants, or you're
working on something so radically new that you need to develope
completely new algorithms, then you can easily spend a man-year
producing no lines of code.)
The important thing, of course, is to be able to measure what
you're doing, so that you can determine whether any change you
make is an improvement or not.
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.
As I said, you might start with the documentation at the SEI
site quoted above. Particularly
http://www.sei.cmu.edu/publications/key-publications.html and
the link to process improvement. Most of what they suggest has
been around for awhile, and has proven its value.
--
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