Superprogrammers
Rommert J. Casimir
are 5 or 6 times as productive as teh average professional programmer.
If such superprogrammers really exist, the field of Software Engineering
is very immature, as in sports whith numeric results (cycling,
athletics) the best professional is at most 10% better than the one who
barely makes a living from his sport.
Hence, I am interested in reports on the selection, education and
employment of such superprogrammers, as well as in reports that expose
their existence as an urban myth.
Of course, I accept that there are programming managers who can
dramatically increase the performance of a team, but my question is on
individual superprogrammers.
--
Rommert J. Casimir
Tilburg University, Room B435, tel 31 13 4662016
P.O. Box 90153, 5000LE Tilburg, The Netherlands
http://cwis.kub.nl/~few/few/BIKA/rc_home.htm
Mattias Lundström
experience, even though this may not be what you asked
for... :-)
Rommert J. Casimir wrote:
>
> From time to time, I read the statement that there are programmers who
> are 5 or 6 times as productive as teh average professional programmer.
>
This is true. Note, though, that with programming I include the
major part of the design process. Once you agree on (and understand)
a design I do not believe that the actual coding work varies
this much in productivity.
I would say that with a long-term measure (so that flexibility,
maintainability and high code quality plays a big part) the
factor can be even higher. If this or a more short-term measure
is the relevant one of course depends on both the business
situation and the product.
> If such superprogrammers really exist, the field of Software Engineering
> is very immature, as in sports whith numeric results (cycling,
> athletics) the best professional is at most 10% better than the one who
> barely makes a living from his sport.
I do not believe this is a valid comparison. There is a big difference
between professional/semi-professional athletes that are up against
the limits of what the human body can physically endure and a programmer
whose skills are both harder to measure and do not have the same
obvious upper limits.
I do however believe that the industry is immature, but I will not
start up this discussion here and now...
> Hence, I am interested in reports on the selection, education and
> employment of such superprogrammers, as well as in reports that expose
> their existence as an urban myth.
One interesting question is of course: Is there a way to either
have an employee selection process to find "super-programmers"
or an education plan that will drastically increase the productivity
of the avarage programmer?
I personally would tend to believe more in the education approach
since I have not seen or heard about any good selection method.
Of course, neither have I really seen a very effective education
program so I may be mistaken (shocking admission, isn't it ;-) )
> Of course, I accept that there are programming managers who can
> dramatically increase the performance of a team, but my question is on
> individual superprogrammers.
A question relevant to this NG:
If we accept the presence of "super-programmers", how should the
SW Eng / project management process take this into consideration?
That's all from me.
- Mattias
Jeffrey McArthur
wrote:
>From time to time, I read the statement that there are programmers who
>are 5 or 6 times as productive as teh average professional programmer.
Let me put a completely different spin on this. How fast can the
programmers type? Programming involves a lot of different things, but one
of the items often overlooked is the speed at which a person can type.
Secondly, how comfortable are they with the editor they use to write code?
If a task is well fully specified, then there may be some visual design, but
in the end, the programmer has to sit down and write the code. If they can
type faster, then they can get the idea down faster. If they get the idea
down faster, there is less time to be distracted by the need to type it.
A second, but related issue, is how fast the person can change the code they
have modified. If they are fast with their editor, they can find and change
code quickly.
My idea boils down to this, if they person is a fast typist, the attention
span needed to get the details of the coding down is less, which means they
are more productive.
Anyone want to comment on this idea?
Jeffrey M\kern-.05em\raise.5ex\hbox{\b c}\kern-.05emArthur
a.k.a. Jeffrey McArthur ATLIS Publishing Services
http://members.home.net/jeffmcarthur/
L. Darrell Ray
>
> I just wanted to give an opinion based on my peronal
> experience, even though this may not be what you asked
> for... :-)
>
> >
> > From time to time, I read the statement that there are programmers who
> > are 5 or 6 times as productive as teh average professional programmer.
> >
>
> major part of the design process. Once you agree on (and understand)
> a design I do not believe that the actual coding work varies
> this much in productivity.
>
> I would say that with a long-term measure (so that flexibility,
> maintainability and high code quality plays a big part) the
> factor can be even higher. If this or a more short-term measure
> is the relevant one of course depends on both the business
> situation and the product.
>
Don't forget that there is also evidence that the *ENVIRONMENT* can
cause the same large difference in productivity!
You also have to be careful of *what* is actually being measured and
called productivity. Even if both applications are reliable, well liked
by the users, etc. I don't consider a developer who produces a 100K (or
500 FP) application in 10 months more productive than one who develops a
20K (or 100FP) application that does the same thing also in 10 months.
An interesting tidbit about productivity. One manager I worked with
involved the development team in deciding who to give awards to after a
project was over (at the end of the post project review ie. postmortem)
by giving everyone on the project a set number of votes (2 or 3 I don't
remember)on who were top contributor. I forget if the top X people were
picked or anyone getting over X number of votes. This manager (and some
of the project members) told me that everyone was often surprised by at
least one of the people picked by this method because to each section of
the project they would not have been one of the top but because they
contributed to so many parts of the project they would get a large
number of votes.
<snip>
>
>
> I personally would tend to believe more in the education approach
> since I have not seen or heard about any good selection method.
> Of course, neither have I really seen a very effective education
> program so I may be mistaken (shocking admission, isn't it ;-) )
>
> > Of course, I accept that there are programming managers who can
> > dramatically increase the performance of a team, but my question is on
> > individual superprogrammers.
>
> A question relevant to this NG:
> If we accept the presence of "super-programmers", how should the
> SW Eng / project management process take this into consideration?
>
> That's all from me.
>
> - Mattias
Except for a project that can be done by one person in isolation the
*Team* aspect is *MORE* important than a super-programmer (especially
self-described super-programmers). Many of the people I've know that
were considered super-programmers actually decreased the productivity of
the team (especially if there was more than one on the team) because
they either fought any decision that was different what they suggested
or ignored the decision and did it the way they wanted which usually
caused a lot of rework. One person I worked with several years ago who
would be considered a super-programmer actually wrote a section of a
product using an unsupported compiler for which he had modified the
standard libraries and did not document the language used, the compiler
used, the fact that the libraries were changed and what the changes
were, how to compile the modifications, etc. so once the bug in the OS
that he had coded a work around for was fixed it was impossible to fix
the product without rewriting a large part of it. It was decided that
this was to expensive so after providing a *binary* patch (luckily the
fix only involved changing the expected value to be returned by the OS)
the customers were notified that further support for the product was
being terminated and they should upgrade to the new product (which ran
on Windows) because we would not be upgrading the product for new
hardware or OS versions for the current platform.
The best people I've worked with were both team players and good at
design\requirements analysis. There are people that could write code
faster and even some who could design and code faster but since they
either could not or would not):
* communicate their designs or
* cooperate in a team environment or
* follow team development rules (SCM, etc.) or
* document what they did so that it could be supported
they were *LESS* effective for the organization.
--
L. Darrell Ray
ASQ Certified Software Quality Engineer
Dade Behring
fa...@ma.aonix.com
> My idea boils down to this, if they person is a fast typist, the
attention
> span needed to get the details of the coding down is less,
which means they
> are more productive.
>
> Anyone want to comment on this idea?
>
Yep. In my 20+ years of developing software, I'd have to say
that typing speed (and by implication, the time attributable to the
mechanics of entering or modifiying code) is among the least
significant of productivity factors in software development.
IMHO, conceptualization and the ability to effectively apply it are
the keys to the craft.
- Ed Falis
Aonix
Danny R. Faught
Mattias Lundström <ehs...@ehpt.com> wrote:
>A question relevant to this NG:
>If we accept the presence of "super-programmers", how should the
>SW Eng / project management process take this into consideration?
I've been talking about review processes lately, and some of the
feedback I've gotten is that the more experienced people, who could
perhaps be "superprogrammers", want to be subjected to less rigorous
review or no reviews (especially code review) at all. I've heard of
giving more scrutiny to inexperienced engineers, but I haven't seen
any press on less review for senior engineers.
My gut response was that these guys need to swallow their egos and get
with the program. However, if they can show the data proving that
this approach is effective, there's no reason to argue with it.
--
Danny Faught -- HP Enterprise Systems Group -- Software Alchemist
"Everything is deeply intertwingled." (Ted Nelson, _Computer Lib_)
Cameron Hayne
>Let me put a completely different spin on this. How fast can the
>programmers type? Programming involves a lot of different things, but one
>of the items often overlooked is the speed at which a person can type.
>[snip]
>If a task is well fully specified, then there may be some visual design, but
>in the end, the programmer has to sit down and write the code. If they can
>type faster, then they can get the idea down faster. If they get the idea
>down faster, there is less time to be distracted by the need to type it.
I think that fast typing may well be a disadvantage. If you are a slow
typist then you might tend to think more about what code you want
to write since it will take longer to write it and longer to change it
if it turns out to be wrong. And to me it is obvious that thinking time
is far more important than coding time. Recall the hare and the tortoise.
--
Cameron Hayne (ha...@crim.ca)
Centre de recherche informatique de Montreal
Martin Tom Brown
cas...@kub.nl "Rommert J. Casimir" wrote:
> From time to time, I read the statement that there are programmers who
> are 5 or 6 times as productive as teh average professional programmer.
More like an order of magnitude or possibly more I'd say.
> If such superprogrammers really exist, the field of Software Engineering
> is very immature, as in sports whith numeric results (cycling,
> athletics) the best professional is at most 10% better than the one who
> barely makes a living from his sport.
Whilst that might be true for physical sports the range of
intellectual skill between say an average club player and
Kasparov in chess is more like the situation for programming.
Essentially the very best are so good that some of their actions
and decisions need careful explaining to lesser mortals.
> Hence, I am interested in reports on the selection, education and
> employment of such superprogrammers, as well as in reports that expose
> their existence as an urban myth.
There are instances in the literature of whole classes of product
which owe their very existance to one determined super programmer.
Spreadsheets for instance.
Regards,
--
Martin Brown <mar...@nezumi.demon.co.uk> __ CIS: 71651,470
Scientific Software Consultancy /^,,)__/
Scott Ellsworth
>In article <35D154A8...@ehpt.com>,
>Mattias Lundström <ehs...@ehpt.com> wrote:
>>A question relevant to this NG:
>>If we accept the presence of "super-programmers", how should the
>>SW Eng / project management process take this into consideration?
>
>I've been talking about review processes lately, and some of the
>feedback I've gotten is that the more experienced people, who could
>perhaps be "superprogrammers", want to be subjected to less rigorous
>review or no reviews (especially code review) at all. I've heard of
>giving more scrutiny to inexperienced engineers, but I haven't seen
>any press on less review for senior engineers.
>
>My gut response was that these guys need to swallow their egos and get
>with the program. However, if they can show the data proving that
>this approach is effective, there's no reason to argue with it.
As best as I can tell, there is a fine line. It is easy to
over-review, run a bad review, or turn it into a circus. Assuming
you have avoided those failure modes, the experienced need the
review as much as the neophytes.
The neophyte should have done the majority of the learning that
the review is going to bring by working with a mentor, so that the
review is not the place where big ugly surprises come out. For
example, a neophyte doing core analysis and design should likely
have talked over enough of the ideas before the review for everyone
to have some confidence in the design. Likewise, if the design is
acceptable, then the code review will not be touching design
issues. This keeps the actual review relatively short. Long reviews
are death, imho.
So, what does a vet get out of a review? If the reviewers are
competent, they are going to see thier ideas challenged. They
will see at least some spots where they have to give ground, and
will see some spots where they have come up with the best module
that the team can present. This keeps them on thier toes, alert,
and up to date.
They will also see spots where they are the only person who can
understand it. The code review is when a piece of code goes from
"Bob's code" to "our code," and it is thus incumbent on the reviewer
to feel that they could maintain the code from that day forth. Thus,
the reviewer is going to call special attention to the toruble spots.
Scott
Scott Ellsworth sc...@eviews.com
"When a great many people are unable to find work, unemployment
results" - Calvin Coolidge, (Stanley Walker, City Editor, p. 131 (1934))
"The barbarian is thwarted at the moat." - Scott Adams
Danny R. Faught
Jeffrey McArthur <jeffmc...@home.com> wrote:
>Let me put a completely different spin on this. How fast can the
>programmers type? Programming involves a lot of different things, but one
>of the items often overlooked is the speed at which a person can type.
I brought this up in our process improvement team a while back.
Everyone laughed, and they tabled the suggestion. I think they were
somehow embarrassed to talk about personal productivity issues. But a
few people (perhaps those who already knew subconsciously that they
needed to improve) ended up using a typing tutor program on their own
and made great progress.
I don't have any data showing the effect on overall productivity. A
lot of my job as a leader is typing email messages, documents, etc.,
so I feel that typing speed does play a noticeable role in my
productivity.
You have to consider accuracy as well (typing tutors do a good job of
tracking this). A fast typist who is overconfident and introduces a
lot of errors in the code is worse than a slow, accurate typist.
>Secondly, how comfortable are they with the editor they use to write code?
Being comfortable doesn't mean they're as productive as they could be.
They may need to get out of a rut. (I'm still using vi myself :-) Get
some people to experiment with different tools, and make sure that team
members have a lot of interaction and that they see how everyone uses
their tools.
Michael Schuerig
> the experienced need the
> review as much as the neophytes.
I don't claim to have experienced this, but I expect senior engineers to
be responsible for the big mistakes. After all it's their job to make
the bigger decisions. And if they do make a mistakes, it's probably not
one of the obvious kind. Rather it's hard to detect and has negative
consequences that may only show up years in the future.
Michael
--
Michael Schuerig
mailto:schu...@acm.org
http://www.uni-bonn.de/~uzs90z/
Michael Trofimov
>
> From time to time, I read the statement that there are programmers who
> are 5 or 6 times as productive as teh average professional programmer.
>
> Hence, I am interested in reports on the selection, education and
> employment of such superprogrammers, as well as in reports that expose
> their existence as an urban myth.
The general point for selection is experience! I think, more than 10 years
experience. This is not possible via any educational process, but only via
practical works.
About employment. The fact is that very often it is very difficult
for an experienced programmer to find a good work. ;-) The majority
of employers do not want to hire an experienced programmer, and
moreover some of employers are afraid to do it. Unfortunately
today, practical software development is oriented to average level,
not to superprogramming level. And, perhaps, there is a lot of
superprogrammers who masked his/her ability to be very productive:
very often in practice it is not possible to pay 5 or 6 average
programmer's salaries to only one person.
Also, another fact is that permanently many of experienced
programmers go to other fields (business, education etc.)...
________________________________________________________________
Michael I. Trofimov
Russian Academy of Sci. Moscow, Russia
email: mtro...@glas.apc.org
http://www.glasnet.ru/~mtrofimov/
________________________________________________________________
jer...@bayone.com
fau...@convex.hp.com (Danny R. Faught) wrote:
> In article <35D154A8...@ehpt.com>,
> Mattias Lundström <ehs...@ehpt.com> wrote:
> >A question relevant to this NG:
> >If we accept the presence of "super-programmers", how should the
> >SW Eng / project management process take this into consideration?
>
> I've been talking about review processes lately, and some of the
> feedback I've gotten is that the more experienced people, who could
> perhaps be "superprogrammers", want to be subjected to less rigorous
> review or no reviews (especially code review) at all. I've heard of
> giving more scrutiny to inexperienced engineers, but I haven't seen
> any press on less review for senior engineers.
>
> My gut response was that these guys need to swallow their egos and get
> with the program. However, if they can show the data proving that
> this approach is effective, there's no reason to argue with it.
Perhaps you could polish their ego's , and suggest that one purpose of
reviews is not only to find defects in the product, but also to educate less
experienced developers.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
News Reader
Rommert J. Casimir wrote in message <35D145...@kub.nl>...
>From time to time, I read the statement that there are programmers who
>are 5 or 6 times as productive as teh average professional programmer.
Since as early as 1968 studies have found a very large gap in developer
productivity. The Sackman, Erickson and Grant study, as summarized in
Yourdon's Decline and Fall, indicates the span from best to worst is a
staggering 28 times in productivity, and 10 times difference in efficiency.
Yourdon reports that same trend has been found over and over again with
General Electric in 79 and Univ. of Maryland in 89.
He also reports Boehm found 90th percentile team is four time more
productive than a 15th percentile team (which makes sense since a team is a
composite of the individuals).
I've worked at companies where I've though I was one of the smartest, and
also at companies where I was continually eclipsed by peers that blew me
away at every turn in the road. I do believe the above figures.
The funny thing is that companies usually figure they can save a few buck by
being "just a little" under a competetive salary. Little do they know how
much they loose. One company I worked at saw "process" as a way to "even
everyone out". Those that liked software left. Those that liked the charts
and graphs stayed.
BTW, the greatest predictor of productivity is.....the number of languages
you know. Years of experience has very little to do with it. Again,
according to Yourdon.
>If such superprogrammers really exist, the field of Software Engineering
>is very immature, as in sports whith numeric results (cycling,
>athletics) the best professional is at most 10% better than the one who
>barely makes a living from his sport.
Not the same. With professional sports you might have 30 starting
quarterbacks, but that is drawn from a pool of more than a few hundred
million people over a period of 10+ years. That's a lot of time for the best
to "bubble up" and a very fine screen with which to grade. For most
development positions, the only prerequisite to call yourself a "developer"
is a degree.
>Hence, I am interested in reports on the selection, education and
>employment of such superprogrammers, as well as in reports that expose
>their existence as an urban myth.
There's a company that handles game programmers like they're hollywood
stars. Their contracts are negotiated by a manager, they get a chunk of the
gross, etc. The product lives and dies on a particular developers ability.
>Of course, I accept that there are programming managers who can
>dramatically increase the performance of a team, but my question is on
>individual superprogrammers.
Hmmmm. Is it safe to say you are in management? I've had one manager in my
career that I thought was absolutely key to team performance. But I've had
several peers that were absolutely indispensible. Much of the time, if you
have a certain type of individual, they do a really good job of talking to
the other team members they need to talk to, schedule meetings outside the
group, staying on top of their self-imposed deadlines. Those environments,
to me, are a dream. At that point you just need someone to make sure the
electricity bill is paid on time :)
In other instances, however, a manager was needed to crack down on the
slackers and hold their feet to the fire. That environment sucked for all
parties involved.
Michael Trofimov
> My idea boils down to this, if they person is a fast typist, the attention
> span needed to get the details of the coding down is less, which means they
> are more productive.
Fast typist is able to type more bugs at the same time... ;-)
As a rule, many different solutions are possible for any non-trivial task.
Productive programmer selects effective solution (for example,
100 lines for writing work, or only 50 lines inspection for debugging
etc.), non-productive programmer selects non-effective solution:
400 lines for writing work, 200 lines inspection for debugging... for
the same task.
BTW, what do you think, is it typing speed very important for book
writing? ;-)
Of course, _normal_ speed is necessary for any person: for programmer,
for superprogrammer, as well as for a writer, a reporter, an Internet user,
etc...
Pete McBreen
Tom Peters reports in one of his recent books about 1000x people, people
who are 1000 times more productive than others. An example he used was
Nintendo, the boos of which was reported to state that there were very few
individuals in teh world capable of repeatedly writing a million seller
game.
> If such superprogrammers really exist, the field of Software Engineering
> is very immature, as in sports with numeric results (cycling,
> athletics) the best professional is at most 10% better than the one who
> barely makes a living from his sport.
Seems like you have the wrong comparison. Yes the good guys may be only a
small margin better (when the limits are muscular), but look at the
win/loss record. My favorite in this catagory is Ed Moses, US 400m Hurdles
supremo, unbeaten for a lot of seasons (6 or 7?).
A better comparison for super programmers would be comparative salaries of
the professional sports people. Then what % difference is there between the
top and bottom?
> Hence, I am interested in reports on the selection, education and
> employment of such superprogrammers, as well as in reports that expose
> their existence as an urban myth.
In many cases, the superprogrammer only looks super in comparison to their
peers. I am personnaly aware of one case where a developer failed over a 10
week period to design and implement a program. While this developer took
their annual 2 week vacation, another developer attempted to fix it for 1
week, then abandoned their design and built it from scratch in 35 hours.
This would be a case for 15x productivity except that the original
developer never delivered the program so we do not know how long it would
have taken :-)
By the way, you need to distinguish between self appointed
"superprogrammers" and skilled developers who are recognized by their peers
as superprogrammers. A useful reference to check out is "Programmers at
Work" by Susam Lammers, published in the early 1908's and documenting many
of the hyper productive individuals who contributed to the microcomputer
industry.
--
Pete McBreen, McBreen.Consulting , Calgary, AB
email: petem...@acm.org http://www.cadvision.com/roshi
Using Creativity and Objects for Process Improvement
Jeffrey C. Dege
>From time to time, I read the statement that there are programmers who
>If such superprogrammers really exist, the field of Software Engineering
>athletics) the best professional is at most 10% better than the one who
>barely makes a living from his sport.
What is missing on these studies is how consistently people perform at
these levels.
I have known people to do some task ten times faster than someone else
would have taken, I have _not_ known people who would always do
every task ten times faster than anyone else would take.
--
Our ability to imagine complex applications will always excede our
ability to develop them.
-- Grady Booch
Alain Picard
Danny> You have to consider accuracy as well (typing tutors do a good job of
Danny> tracking this). A fast typist who is overconfident and introduces a
Danny> lot of errors in the code is worse than a slow, accurate typist.
Is this serious, or is this poster jesting? Does he really think
that typing inaccuracies are a serious cause of bugs?
I've found that muddled thinking, sloppy craftsmanship, lack
of discipline and plain laziness are far worse problems.
(And I include myself as one of the offenders, at least occasionally)
--ap
--
It would be difficult to construe Larry Wall, in article
this as a feature. <1995May29....@netlabs.com>
Rommert J. Casimir
>
> A better comparison for super programmers would be comparative salaries of
> the professional sports people. Then what % difference is there between the
> top and bottom?
This is exactly my point. The top player may earn 100 times as much as
the one who barely makes a living from his sport, but who is going to
pay the superprogrammer 5 even five times the salary of the average
programmer, unless he is also a enterpreneur (but many people who have
got rich in software debelopment are no programmers themselves)
> > Hence, I am interested in reports on the selection, education and
> > employment of such superprogrammers, as well as in reports that expose
> > their existence as an urban myth.
> In many cases, the superprogrammer only looks super in comparison to their
> peers. I am personnaly aware of one case where a developer failed over a 10
> week period to design and implement a program. While this developer took
> their annual 2 week vacation, another developer attempted to fix it for 1
> week, then abandoned their design and built it from scratch in 35 hours.
> This would be a case for 15x productivity except that the original
> developer never delivered the program so we do not know how long it would
> have taken :-)
In what other profession would it have been possible that such an
incompetent person would have been hired and presumably paid about the
same salary as the person who was 15 times as productive?
> By the way, you need to distinguish between self appointed
> "superprogrammers" and skilled developers who are recognized by their peers
> as superprogrammers. A useful reference to check out is "Programmers at
> Work" by Susam Lammers, published in the early 1908's and documenting many
> of the hyper productive individuals who contributed to the microcomputer
> industry.
The existence of "self appointed superprogrammers" is also curious. No
sensible amateur chess player would boast that he would easily win from
Kasparov if he got the chance to play him.
From other contributors on this topic I get the impression that
superprogrammers exist, but are not liked by managers. In taht case, it
might be a good idea to employ sports managers in Software Engineering
organizations
> --
> Pete McBreen, McBreen.Consulting , Calgary, AB
> email: petem...@acm.org http://www.cadvision.com/roshi
> Using Creativity and Objects for Process Improvement
--
Christopher Barber
> >>>>> Danny R Faught writes:
>
> Danny> You have to consider accuracy as well (typing tutors do a good job of
> Danny> tracking this). A fast typist who is overconfident and introduces a
> Danny> lot of errors in the code is worse than a slow, accurate typist.
>
> Is this serious, or is this poster jesting? Does he really think
> that typing inaccuracies are a serious cause of bugs?
Without question typos are a significant cause of bugs. Essentially any
type of problem that is not caught by the compiler will become a bug.
This is especially true in non-compiled languages such as Tcl and Perl;
typos frequently are the cause of bugs in those languages. In compiled
languages typos more often impact documentation, error messages and the
like, but even those are still bugs.
--
Christopher Barber ----- Software Engineer ---- D.E.Shaw & Co.
Tom J
quoted:
>> By the way, you need to distinguish between self appointed
>> "superprogrammers" and skilled developers who are recognized by their peers
>> as superprogrammers.
Superprogrammers have no peers to make this judgement.
>The existence of "self appointed superprogrammers" is also curious. No
>sensible amateur chess player would boast that he would easily win from
>Kasparov if he got the chance to play him.
It is my impression that chess players have an absolutely unambiguous scoring
scheme for placing rank. Software will never have any predictable
ranking scheme.
Slow typists are also inacurate typists, from what I can tell.
The Personal Software Process can probably make most people 25% more
productive and help them produce 10 times fewer bugs. I believe
--
Tom Janzen - tej at world dot std dot com USA Dist. Real-Time Data Acquisition
S/W for Science and Eng. under POSIX, C, C++, X, Motif, Graphics, Audio
http://world.std.com/~tej
Ralph Stamerjohn
Rommert J. Casimir wrote:
> From time to time, I read the statement that there are programmers who
> are 5 or 6 times as productive as teh average professional programmer.
> ...
> Of course, I accept that there are programming managers who can
> dramatically increase the performance of a team, but my question is on
> individual superprogrammers.
>
>
In the late 1970's the West German government commissioned a study on
superprogrammers and found 1) yes, there are some and 2) this is how they
tick.
At the 1978(?) DECUS European Symposia in Canne, France, I listen to a paper
by someone from this study. It was eye opening. I lost my copy about 10
years and I'm still searching for a replacement.
Basic premise is of the processes in the human brain, three are involved
with programming: visual, kinetic, and linguistic. The classic everyday
programmer does almost everything using the linguistic (deals with symbols,
typing, and so forth).
A Superprogrammer starts with the visual and kinetic. His visual system
draws a picture. The kinetic does a simple binary yes/no on the picture. The
visual processes makes a change to the picture. The process repeats
multiple times a second for thousands and millions of iterations. (In the
mean time, the superprogrammer appears to the world to be staring off into
space). When program is done, the superprogrammer freezes the image into
permanent storage, turns on the linguistic systems, and outputs the program.
Note, this is how design/coding are done. Analysis is still a different
beast.
The best thing about the study was training techniques to help people learn
visualization and was to save visual images across interruptions.
This paper was a major influence in my career. Someone should dust off the
old study and open it up again now that we have GUI's, web, and so forth.
Ralph Stamerjohn
rstam...@qgraph.com
Mattias Lundström
L. Darrell Ray wrote:
>
> Mattias Lundström wrote:
> >
> > I just wanted to give an opinion based on my peronal
> > experience, even though this may not be what you asked
> > for... :-)
> >
> > Rommert J. Casimir wrote:
> > >
> > > From time to time, I read the statement that there are programmers who
> > > are 5 or 6 times as productive as teh average professional programmer.
> > >
> > I would say that with a long-term measure (so that flexibility,
> > maintainability and high code quality plays a big part) the
> > factor can be even higher. If this or a more short-term measure
> > is the relevant one of course depends on both the business
> > situation and the product.
> >
>
> Don't forget that there is also evidence that the *ENVIRONMENT* can
> cause the same large difference in productivity!
Yes. But let us assume a constant environment when doing the
comparison to limit the discussion...
> You also have to be careful of *what* is actually being measured and
> called productivity. Even if both applications are reliable, well liked
Exactly. I would say it is exceedingly difficult to find a good
quantifyable measure. Which measure is best also depends on the
business case and product requirements, lifecycle etc.
> > A question relevant to this NG:
> > If we accept the presence of "super-programmers", how should the
> > SW Eng / project management process take this into consideration?
> >
> > That's all from me.
> >
> > - Mattias
>
> Except for a project that can be done by one person in isolation the
> *Team* aspect is *MORE* important than a super-programmer (especially
> self-described super-programmers). Many of the people I've know that
> were considered super-programmers actually decreased the productivity of
> the team (especially if there was more than one on the team) because
Let us define "super-programmer" means 5-6 times better than average
according to some _good_ measure. What you are saying is that
very often super-programmer != perceived super-programmer.
I will agree with you that this is true.
NOTE: I am NOT saying that the wild "cowboy hacker" is a productive
project member. :-)
[snip - a lot of examples of bad programming practices by
"perceived super-programmers"]
On the other hand it is very important to recognize that the
productivity between different programmers can vary strongly
also between members of the same classification (senior/junior
programmer).
Otherwise you get one of my least favourite parts of the
project process at my place of work:
You break up the project in work packages and get time estimates
for each WP in manhours. _Then_ you assign the people that will
work in each WP.
Result: Very bad precision in the estimates...
-- Mattias
Michael Trofimov
> BTW, the greatest predictor of productivity is.....the number of languages
> you know. Years of experience has very little to do with it. Again,
> according to Yourdon.
What does it mean "the number of languages you know"? I.e. if
you had read technical documentation of language Noname, and wrote
three small Noname programs, but did not use the language any more,
does it mean that "you know language Noname"? and does it mean
that your productivity was increased by your games with Noname?
A few years ago, during 8 months, I observed a team: there were
three young programmers (two years experience; TASM, Turbo Pascal,
C/C++, PROLOG, BASIC, FORTRAN-4) and one old programmer (20+ years
experience; FORTRAN-4, only!) in the team. The old man was much more
productive than all the young ones in sum!
Michael Trofimov
> From other contributors on this topic I get the impression that
> superprogrammers exist, but are not liked by managers. In taht case, it
> might be a good idea to employ sports managers in Software Engineering
> organizations
Good idea! :-))
Perhaps, it would be better to append some methodologies from sport
management to SE.
Scott Ellsworth
<6qsjkp$6...@feep.rsn.hp.com> wrote:
>>>>>> Danny R Faught writes:
>
>Danny> You have to consider accuracy as well (typing tutors do a good job of
>Danny> tracking this). A fast typist who is overconfident and introduces a
>Danny> lot of errors in the code is worse than a slow, accurate typist.
>
>Is this serious, or is this poster jesting? Does he really think
>that typing inaccuracies are a serious cause of bugs?
Yep, I have found it so. Not a lot of them, but enough to be
noticed, and to be worth fixing if the cost is not high. For
example:
x=y=z
vs
x=y==z
or
x=y-z
All of these are valid code, and will only issue a warning in the
second case. All of them were also actual typos, since the - key
is next to the = key on a standard IBM 101 key american keybaord.
So, is this a serious cause of bugs? Not compared to poor thinking,
laziness, and so on, but it is in the list, and it is easier to fix
than poor thinking. If it is easy to fix, then why not do so?
For what it is worth, my own coding standard never uses x=y=z. If I
want an assign, it gets its own lin. This way, when I read code, the
first line would stand out when I review it.
>I've found that muddled thinking, sloppy craftsmanship, lack
>of discipline and plain laziness are far worse problems.
>(And I include myself as one of the offenders, at least occasionally)
Of course, but fixing muddled thinking often requires change across an
entire organization, while fixing typing errors merely requires a bit
of keyboard training. That bit of keyboarding is fast enough that
most developers I know have done it already, while fixing the sick
organizations is something that all of them want to do, and few
of them get the chance to do.
Martin Tom Brown
t...@world.std.com "Tom J" wrote:
> In article <35D2A7...@kub.nl>, Rommert J. Casimir <cas...@kub.nl> wrote:
> quoted:
> >> By the way, you need to distinguish between self appointed
> >> "superprogrammers" and skilled developers who are recognized by their peers
> >> as superprogrammers.
>
> Superprogrammers have no peers to make this judgement.
Perhaps only their peers can make an accurate judgement on that,
but it is obvious to me that a couple of the people I have had
contact with (and one in hardware too) were in this league.
Though they would no doubt deny it.
> >The existence of "self appointed superprogrammers" is also curious. No
> >sensible amateur chess player would boast that he would easily win from
> >Kasparov if he got the chance to play him.
>
> It is my impression that chess players have an absolutely unambiguous scoring
> scheme for placing rank. Software will never have any predictable
> ranking scheme.
Why so defeatist? I see no compelling reason why ability to analyse
problems and program computers cannot be measured unambiguously.
That we have not yet managed to do so shows one of our limitations.
> Slow typists are also inacurate typists, from what I can tell.
Depends. I have known fast accurate typists that span the whole
range of programming ability. It is unusual to find a highly
productive slow typist I will grant you that.
> The Personal Software Process can probably make most people 25% more
> productive and help them produce 10 times fewer bugs. I believe
There is always room for improvement.
Scott Ellsworth
>Scott Ellsworth <sc...@eviews.com> wrote:
>
>> the experienced need the
>> review as much as the neophytes.
>
>I don't claim to have experienced this, but I expect senior engineers to
>be responsible for the big mistakes. After all it's their job to make
>the bigger decisions. And if they do make a mistakes, it's probably not
>one of the obvious kind. Rather it's hard to detect and has negative
>consequences that may only show up years in the future.
You crystalized something for me. Thank you.
The people in charge of the big pieces often are quite convincing,
even when they are wrong. For example, one that I know of made a
major mistake in an implementation decision that caused the entire
project to use the internals of a very low level module directly.
Changing that was a lot of fun.
Because the person making the bad call was experienced, and
right so often, people tended not to argue. They knew that an
argument would end in them being incorrect, and it is a hard thing
for people to fight a battle they know they will lose.
John Atwood
of him talking about these 3 modes of thinking (from
Bruner and Piaget).
Please let me know if you get more specific info on this paper.
How is analysis done?
John
----------------------------------
Tim McDermott
Mattias Lundström wrote:
> I just wanted to give an opinion based on my peronal
> experience, even though this may not be what you asked
> for... :-)
>
> Rommert J. Casimir wrote:
> >
> > From time to time, I read the statement that there are programmers who
> > are 5 or 6 times as productive as teh average professional programmer.
> >
Of course they exist. Bill Curtis (now with Microsoft, I think) has published
extensively on them. When he was at MCC, he ran a "talk-aloud" experiment in
which people were given a toy design problem (an elevator control system) and
asked to talk through their design process. He demonstrated that some of his
subjects (junior folks at MCC had PhDs with 3 yrs experience; reps from the
shareholding companies typically had 15-20 years experience) were obviously,
significantly better than others. The salient attributes of the
superprogrammers in this experiment was that they could look at the problem
from multiple paradigms and slide up and down levels of abstraction easily.
> > Hence, I am interested in reports on the selection, education and
> > employment of such superprogrammers, as well as in reports that expose
> > their existence as an urban myth.
>
> One interesting question is of course: Is there a way to either
> have an employee selection process to find "super-programmers"
> or an education plan that will drastically increase the productivity
> of the avarage programmer?
Back when I was active in the CASE world, there was a silent, but real, debate
over the direction that software technology should go. Should we figure out
how superprogrammers operate and build tools to make them even more
productive, or build tools to boost the "masses of asses." (A real quote from
the technology VP of a $5 billion company) For economic reasons, tool vendors
obviously aimed their tools at the mediocre -- its a _much_ bigger market.
> I personally would tend to believe more in the education approach
> since I have not seen or heard about any good selection method.
> Of course, neither have I really seen a very effective education
> program so I may be mistaken (shocking admission, isn't it ;-)
I am perfectly confident that universities are utterly incompetent at training
superprogrammers. They can't do much more than programming in the small.
This is mostly a matter of scale; there isn't enough time in an academic
program to allow even one development of industrial scale, so it is very hard
to give students experience in what the real world is like. I personally
think SPs develop themselves.
Another interesting issue is how many superprogrammers there are. When Harlan
Mills developed the Chief Programmer (CP) technique he was working for IBM.
Now with a Harlan Mills at the helm, CP is a wonderful approach. But a
colleague of a colleague asked an IBM exec how many CP they had back then.
Answer, 50. How many did they need? 500. If IBM at the height of their
power could only find 10% of the superprogrammers they needed, perhaps there
just aren't that many.
Tim
Tim McDermott
L. Darrell Ray wrote:snip
> One person I worked with several years ago who
> would be considered a super-programmer actually wrote a section of a
> product using an unsupported compiler for which he had modified the
> standard libraries and did not document the language used, the compiler
> used, the fact that the libraries were changed and what the changes
> were, how to compile the modifications, etc. so once the bug in the OS
> that he had coded a work around for was fixed it was impossible to fix
> the product without rewriting a large part of it. It was decided that
> this was to expensive so after providing a *binary* patch (luckily the
> fix only involved changing the expected value to be returned by the OS)
> the customers were notified that further support for the product was
> being terminated and they should upgrade to the new product (which ran
> on Windows) because we would not be upgrading the product for new
> hardware or OS versions for the current platform.
I suspect you have never met a superprogrammer. Hot-dogs are common, SPs are
not.
> The best people I've worked with were both team players and good at
> design\requirements analysis. There are people that could write code
> faster and even some who could design and code faster but since they
> either could not or would not):
> * communicate their designs or
> * cooperate in a team environment or
> * follow team development rules (SCM, etc.) or
> * document what they did so that it could be supported
> they were *LESS* effective for the organization.
The most valuable skills of SPs are not in coding. As a rule of thumb, coding
is 10% of development, so coding skill can hardly affect an order of magnitude
difference in effectiveness. SPs get their leverage from better requirements
analysis and design. But if that is what SPs are good at, almost any
organization will surround them with people to do the actual coding, testing,
and even documenting. So by my definition of SPs, they have to be good at all
the things on your list, and a few more, like teaching.
Tim
Gene Gajewski
Tim McDermott wrote in message <35D37206...@draper.com>...
>
<snip>
Good call - there needs to be a differentiation between a blowhard hotdog
programmer with an inflated ego, and an SP. I would venture that some SP's
get labeled as hotdogs simply because they are more effective and
supervisors view them as an enigma to be distrusted, a threat to their
career.
SP's have a need to communicate, enjoy working in a team environment,
understand CM practices perfectly, insist on documenting.
The sorry part is, the SP enjoys what he does and has little enthusiasm for
his supervisors management position, and so he suffers for nothing.
The SP phenomenon is not limited to programming - it exists in all manner of
occupations in which critical thinking and analysis is part of the job.
Pete McBreen
<35D2A7...@kub.nl>...
> Pete McBreen wrote:
> > This would be a case for 15x productivity except that the original
> > developer never delivered the program so we do not know how long it
would
> > have taken :-)
>
> In what other profession would it have been possible that such an
> incompetent person would have been hired and presumably paid about the
> same salary as the person who was 15 times as productive?
This follows on from the "free game" theory of software development. If you
are successful in delivering software (meaning that the development costs
were less than the resulting revenue stream) then you get to play the game
again. In the case I reported, both developers were successful by this
measure. They had delivered applications and the company had made a profit.
It was only when they worked on the same project that the discrepancy
between their productivity became apparent.
Measuring productivity in software development has been an issue for a long
time. We know we are not good at estimating how long an application will
take to develop, so how do we measure productivity? Or as many other
discussions have covered which attributes of an application should we
measure and what classifies as good? In many cases the business decision is
that shorter development times are good (even if this means we push a lot
of the costs into the maintenance arena).
> From other contributors on this topic I get the impression that
> superprogrammers exist, but are not liked by managers. In that case, it
> might be a good idea to employ sports managers in Software Engineering
> organizations
SPs not being liked is probably a misnomer. Self appointed SPs are
disliked, since they are never as good as they like to think they are, and
they come with a big (insecure) ego.
A true SP (as recognized by their peers) is liked by managers, since they
are able to deliver without excuses.
Having said that however, the idea of getting new ideas into software
management is a great one. As a good starting point for this see "Managing
Software Maniacs" by Ken Whitaker.
L. Darrell Ray
>
> L. Darrell Ray wrote:
>snip<
>
> not.
Actually the guy was *VERY* good he just did not like to do the mundane
parts of the job once the *interesting* (i.e. difficult) parts were
done. When given some support and told he had to document his work and
use SCM he met *ALL* the criteria for a super-programmer but left to his
own his stuff was not maintainable.
>
> > The best people I've worked with were both team players and good at
> > design\requirements analysis. There are people that could write code
> > faster and even some who could design and code faster but since they
> > either could not or would not):
> > * communicate their designs or
> > * cooperate in a team environment or
> > * follow team development rules (SCM, etc.) or
> > * document what they did so that it could be supported
> > they were *LESS* effective for the organization.
>
> The most valuable skills of SPs are not in coding. As a rule of thumb, coding
> is 10% of development, so coding skill can hardly affect an order of magnitude
> difference in effectiveness. SPs get their leverage from better requirements
> analysis and design. But if that is what SPs are good at, almost any
> organization will surround them with people to do the actual coding, testing,
> and even documenting. So by my definition of SPs, they have to be good at all
> the things on your list, and a few more, like teaching.
>
> Tim
Yes a Super-Developer (to differentiate from someone just skilled at
coding) has to also be very good at design (although not IMO
necessarially at initial analysis which is a different skill set).
Another problem with Super-Developers is that they become very used to
having their opinion deferred to (having been right so often they are
very confident that what they suggest is the best option)and having been
on a couple of teams for critical projects that management staffed with
the best available including a couple of Super-Developers I know that
having several people used to having their technical opinions deferred
to in the same meeting trying to decide technical issues can cause lots
of problems.
--
L. Darrell Ray
ASQ Certified Software Quality Engineer
Dade Behring
.
Frank Adrian
>My idea boils down to this, if they person is a fast typist, the attention
>span needed to get the details of the coding down is less, which means they
>are more productive.
>
So it is obvious - secretaries and admin. assts., if properly trained, will
be the best programmers :-). The bottom line is that, all other things
being equal, yes, a faster typist will be more productive. But the
differential, given the vastly greater amount of time done in pre- and
post-coding work, will be utterly insignificant. And the time you waste to
determine skill in this area will insure that you make a less well informed
choice in other, more salient areas of the job. Anyone who seriously uses
this criteria on an evaluation for a programmer is seriously screwed up.
--
Frank A. Adrian
First DataBank
frank_...@firstdatabank.com (W)
fra...@europa.com (H)
This message does not necessarily reflect those of my employer,
its parent company, or any of the co-subsidiaries of the parent
company.
Frank Adrian
>My gut response was that these guys need to swallow their egos and get
>with the program. However, if they can show the data proving that
>this approach is effective, there's no reason to argue with it.
It depends what the code review is for. In many orgs, a CR is simply a
vehicle for sniping at a design because it wasn't done the way someone else
liked (a problem from both the high and low ends). As long as you avoid
this, most "superprogrammers" don't actively avoid reviews. There are a few
things that can make them less than pleasant for the SP, though:
(1) SP's often use algorithms and frameworks that are abstract and elegant
and have "extraneous" code and/or constructs that maximize long-term
features (such as extensibility) and that seem overly complex and useless to
the less experienced programmers. Having to take a large amount of time to
explain these aspects of a correct design is often tedious and seen as
unproductive.
(2) SP's often underdocument their code - not necessarily because they're
prima donnas - but usually because what seems "obvious" to them is not
"obvious" to less experienced programmers. These "missing comments" often
become a point of contention in formal reviews.
(3) SP's are often overworked and view the price/performance ratio of the
review as being large - they do a lot of explaining and get small amounts of
improved quality in return.
Bottom line, there is a disconnect in the SP's level of programming skill
and most other engineers' that must be bridged. A formal "review process"
often blows up this difference in skill levels into an adversarial situation
rather than facilitating a cooperative effort to bridge the experience
levels.
So, how do you get around this? Mainly, don't make it a review - in most
cases, the SP (if he really is an SP) doesn't need much of that - I'd call
it an seminar, where the SP can show the newer staff members what he's done
with the code, explain why the system works as it does, and let others ask
questions. If someone does find a defect, most real SP's will accept this
graciously.
Second, if you feel that a formal review is really necessary, couch it in
terms of the fact that ALL team members get their work reviewed and
emphasize the teamwork aspect of going through with the review and the
educational impact of the SP's code on the less experienced programmers.
Let the SP know that answering questions from the less experienced
developers will often enlighten them about a particular aspect of the design
that they might not have thought about.
In the final analysis, it's a political sell. Did you expect that managing
would be other than a political job? You won't keep your best employees if
you tell them to do it because you said so (even though that's eventually
what it boils down to).
Now if you have someone who think's they're an SP, but aren't, well, you've
got another problem entirely and even I think that, in that case, you should
tell them to "swallow their egos and get with the program".
Frank Adrian
>Rommert J. Casimir wrote:
>
>> From other contributors on this topic I get the impression that
>> might be a good idea to employ sports managers in Software Engineering
>> organizations
>
>Perhaps, it would be better to append some methodologies from sport
>management to SE.
Especially WRT compensation...
Frank Adrian
>I am perfectly confident that universities are utterly incompetent at
training
>superprogrammers. They can't do much more than programming in the small.
>This is mostly a matter of scale; there isn't enough time in an academic
>program to allow even one development of industrial scale, so it is very
hard
>to give students experience in what the real world is like.
It seems a shame that many companies are also tending to buy into this
"short-term" mindset, attempting to replace more experienced programmers
with young ones, often keeping programmers for a maximum of 4 or 5 years
before the next round of "productivity enhancing" layoffs. One wonders how
one is going to gain experience in a company's business with that type of
timeframe.
>Another interesting issue is how many superprogrammers there are. When
Harlan
>Mills developed the Chief Programmer (CP) technique he was working for IBM.
>Now with a Harlan Mills at the helm, CP is a wonderful approach. But a
>colleague of a colleague asked an IBM exec how many CP they had back then.
>Answer, 50. How many did they need? 500. If IBM at the height of their
>power could only find 10% of the superprogrammers they needed, perhaps
there
>just aren't that many.
Or maybe they weren't willing to provide the proper environment (those were
the days of IBM's white shirts and black ties when the rest of the world was
starting to get into jeans and tie-dye shirts) or pay (at that time,
probably not) or career advancement opportunities (almost always) for their
chief programmers? Most labor shortages in the real world boil down to lack
of willingness to pay in some form. Give me enough $'s and the right
environment and I'll show you all the superprogrammers you can use.
JRStern
>I think that fast typing may well be a disadvantage. If you are a slow
>typist then you might tend to think more about what code you want
>to write since it will take longer to write it and longer to change it
>if it turns out to be wrong. And to me it is obvious that thinking time
>is far more important than coding time. Recall the hare and the tortoise.
Certainly you have a line on your resume that says, "I'm a hunt and
peck typist, so hire me instead of those slick guys who touch type."
Joshua Stern
JRS...@gte.net
JRStern
<mcbr...@cadvision.com> wrote:
>A true SP (as recognized by their peers) is liked by managers, since they
>are able to deliver without excuses.
In a situation where the SP is 10x productive over the average, at
maybe 2x the salary, it's likely somebody will be unhappy -- the
manager at paying 2x the salary, or the SP at the 5x gap (yes, I know
this is not an enlightened self-interest view by the manager, but it's
common enough).
Once in twenty years in this industry, I worked in a situation where,
out of ten developers, four were fast, dependable, and worked well
independently and effectively from the sketchiest guideliness. I've
never in twenty years seen anybody better than any of these four.
Oddly, I think the four knew who they were, the other six did not, and
management didn't have a clue.
FWIW.
Joshua Stern
JRS...@gte.net
Chris
guys (and women) who at some point in their career have been called this, I
have myself on several occasions too. Personally, I believe people in this
category can actually do a Company more harm than good. I'll try too
explain, if you get a couple of these people on to a single project and the
project manager provides them with the level of control they need (usual
none at all, as they will just develop the project off their own back), what
does this do for future projects?
I work on several small projects (10-20,000 SLOC) which we completed on time
and to budget (in less than 5 months), no overtime was available as we were
using rented accommodation and the owners locked up at the end of normal
working hours. The stress level on these projects was huge, and it had
physical effects on all members of the team, I used to suffer from
horrendous spontaneous nose bleeds and the other people had symptoms of high
blood pressure.
So what happened the next time the Company was asked to tender for a project
of similar size?
The bid team put together a similar timescale and cost, unfortunately the
people involved in the first project had other commitments and the project
team allocated did not have any 'hereos'. The project was hugely overspent
and delivery was late, the Customer was not happy. The reported lesson
learnt was that the estimate was unachievable and the project team did not
perform as well as it should have done, due to several excuses/reasons and
not that the first project was manned by hereos.
Hereos and superprogrammers have their place in an organisation but
management have to be aware of who they are and their availability for
involvement in projects.
Personally I believe the most important aspect of performing a job right and
completed on schedule are for an organisation to have a good set of defined
processes (using the Michael Hammer definition of a process) and not to rely
on hereos to dig a project out of a grave.
Best Regards
Chris
Michael Trofimov
> Basic premise is of the processes in the human brain, three are involved
> with programming: visual, kinetic, and linguistic. The classic everyday
> programmer does almost everything using the linguistic (deals with symbols,
> typing, and so forth).
>
> A Superprogrammer starts with the visual and kinetic. His visual system
> draws a picture. The kinetic does a simple binary yes/no on the picture. The
> visual processes makes a change to the picture. The process repeats
> multiple times a second for thousands and millions of iterations. (In the
> mean time, the superprogrammer appears to the world to be staring off into
> space). When program is done, the superprogrammer freezes the image into
> permanent storage, turns on the linguistic systems, and outputs the program.
I think one limitation is quite necessary for this discussion: today
standard science is capable to study only normal phenomena! As for
me, I would be ready to believe that somebody is able to calculate
an expression 125439898765231240432013**1/23178493 for only 1/26 of
second (mental arithmetic!), but (unfortunately) current standard
(conservative) science is unable to explain such so-called
para-normal phenomenon. And I think it has no sense to try
discussing any "magic" abilities of the human brain: fortunately or
unfortunately they are not very distributed. Perhaps, someone is
able to be 1000 times productive, but let's speak about
superprogrammers and do not speak about supermen!
Michael Trofimov
> > From other contributors on this topic I get the impression that
> > superprogrammers exist, but are not liked by managers. In that case, it
> > might be a good idea to employ sports managers in Software Engineering
> > organizations
> SPs not being liked is probably a misnomer. Self appointed SPs are
> disliked, since they are never as good as they like to think they are, and
> they come with a big (insecure) ego.
>
> A true SP (as recognized by their peers) is liked by managers, since they
> are able to deliver without excuses.
>
Yes, I do agree that true SP is liked by managers, but managers dislike
problems which may be linked with SP:
1) Risk. Unfortunately, everybody may be ill, or moreover may die :-((
In this case, the manager must to find immediately : a) another SP;
b) 5-6 ordinal programmers (OP)...
2) Security. If OP steals source code he had written (often it may be easy
than to steal a code written by others) -- then it would be a small pice
of entire project. In contrast, if SP steals code he had written -- it would
be significant part...
3) Possible conflict situations: SP would be much more dangerous
than OP.
4) No challenge. For short time period all members of the team (OPs)
will see that they are unable to compete with SP. Any programming
challenge would be invalid in this situation...
5) Permanet leader/ superman war. In the case of there is only one
SP in the team, he will be permanet leader of the team, but if
there are two SPs in one team, the superman war may be possible -- the
both cases are not suitable for the team manager...
6) Another extremal (or even criminal) situations: a woman from the
team and SP... some interested OP from the team wants 'to improve'
the situation...
etc.
Chris Cawsey
Giovanni 8 wrote:
> Have you ever noticed how much faster it is to re-work a
> lost or botched set of routines than it was to create them
> the 1st time around. That time of endless errors is not
> wasted. It's the learning phase... learning what doesn't
> work.
Don't take this the wrong way, I'm not trying to holyer-than-thou anyone,
just pass on my experiences...
The shockingingly high speed of re-doing occasional lost or botched code
was apparent to me and my workmates, until we realised that the
design-on-the-fly coding was responsible not just for the comparative high
speed of re-implementation, but often the need for re-implementation at
all. Also, the re-implementation was only 'fast' relative to the enormous
time-cost of doing to much implementation design during coding. We found it
was much more time-efficient to completely design the implementation unit
prior to doing one line of real-code, the only code coming from the
process, if any, being prototype implementations of high risk, highly
mathematical or technical parts identified by the design process. The
point, we found, was that errors are much cheaper to fix in the design than
during implementation. Of course we're not taking credit for this
"discovery", plenty of others in this NG will have known this for years,
and it is very-well documented in half-decent SE books.
Without wanting to take the thread too much off-topic, what baffles me is
the hostility shown by some to these ideas, who see low-level-design as
pretentious intellectualism or pompous self-righteousness - and are
completely oblivious to the problems its causing them.
What's even more worrying is that CS graduates are not being taught this
stuff, it makes one wonder what they are being taught. In some ways having
to "book and wait" for computing time in the old days accidentally forced
better design practice, which should now be formally learnt and taught
alongside the constantly available development platforms.
Cheers,
Chris Cawsey
Fintan Swanton
> gio+van+no+ni+8@tal+star+spam.com (Giovanni 8) wrote:
>
> >It's one thing to ask a colleague to take a look at your code;
> >it's a completely different thing for there to be a forced
> >formal review.
>
> I don't understand what's wrong with forced reviews. <snip>
If you examine the literature, you will see that a key prerequisite for
effective formal reviews is the willing participation of those involved. For
example, Tom Gilb & Dorothy Graham are adamant in "Software Inspection" that
nothing should be subjected to inspection without the consent of its author.
Fintan.
Stephen Bleakley
>
> The shockingingly high speed of re-doing occasional lost or botched code
> was apparent to me and my workmates, until we realised that the
> design-on-the-fly coding was responsible not just for the comparative high
> speed of re-implementation, but often the need for re-implementation at
> all.
I agree. People who have to type fast to get their design ideas into
code before they forget them seem to be going about the whole design
process wrong.
I am not a die-hard believer of spending months and months
over-designing on CASE tools, but surely the design of a
program/algorithm/system should be done before the coding phase is
started.
A superprogrammer is someone who produces reasonable design docs which
will help him/her have a relatively short code phase - no matter what
speed they type.
Higher productivity is gained by not having to debug and rework.
Stephen
--
Stephen Bleakley
Software Systems - Systems Lab
Philips Semiconductors, Southampton
Scott Ellsworth
..
>It's one thing to ask a colleague to take a look at your code;
>it's a completely different thing for there to be a forced
>formal review.
[Other, very good Deming points deleted.]
> 3. Evaluation of performance, merit rating, or annual review.*************
True, but I would be surprised if Deming was opposed to the kind of
code review I thought the person who started this was asking about.
A developer produces more than just code, so reviews have a place
in his methodology, as long as they are vehicles for information
transfer, not putative and are often enough to be useful. For me,
on the order of weekly or monthly is appropriate, since that is about
how long progress takes me.
1. A review produces training for those who do not have the same
experience. They may well be just as competent, but if you have
struggled with nonlinear solvers for two weeks, and they have not,
it might help them to know what the issues were.
2. A review spreads and lowers risk - you do not have to worry that
you will be the one who has to come in on a weekend to fix a
problem, since the entire team will have at least passing knowledge.
3. A review acts as a way for the people running the project to give
feedback on how your part is going. You will not be surprised by
thier needs if they are talking to you on a weekly basis about how
your present task is going, and giving you ramp up information for
the next one.
A review can, of course, become putative, too infrequent, and a waste
of time. In which case, Deming's complaints about it stand.
Dan Drake
8) wrote:
>...
>
> Have you ever noticed how much faster it is to re-work a
> lost or botched set of routines than it was to create them
> the 1st time around. That time of endless errors is not
> wasted. It's the learning phase... learning what doesn't
> work.
>
>...
Anyone who has been around long enough has surely run into these two
management criticisms of programmers:
1. They never want to fix anything, they just rewrite the whole thing
from scratch their own way, the damn prima donnas.
2. They never re-work a bad job, they just hack and patch and patch and
hack, the sloppy bums.
These are closely related to "They always want to build a Cadillac when a
Ford would do" and "They just patch together some quick junk that pretty
much works for a little while."
We have piped unto you, and ye haveú
not danced; we have mourned to you,ú
and ye have not wept.ú
Luke 7:32
It's an old problem.
--
Dan Drake
d...@dandrake.com
http://www.dandrake.com/index.html
Howard Fear
fau...@convex.hp.com (Danny R. Faught) writes:
> I've been talking about review processes lately, and some of the
> feedback I've gotten is that the more experienced people, who could
> perhaps be "superprogrammers", want to be subjected to less rigorous
> review or no reviews (especially code review) at all. I've heard of
> giving more scrutiny to inexperienced engineers, but I haven't seen
> any press on less review for senior engineers.
My experience is somewhat opposite. The Master programmers I've run
across want their code reviewed. In a pinch, they may prioritize the
code that gets reviewed based on risk. But, overall, they understand
the benefits of reviews and actively support them.
Management is often a different story feeling that its a waste of time
to review their Master programmer's work.
Personally, I tend to vacillate. In general, I think that the Master
programmer should be allowed to forgo reviews on code they've determined
to be non-risky. On the other hand, they also need to make the trade-off
of when a code review would be instructive to the reviewers in
addition to a quality control technique.
--
Howard Fear email: howar...@pageplus.com
http://www.pageplus.com/~hsf/
Stuart Park
: Good call - there needs to be a differentiation between a blowhard hotdog
: programmer with an inflated ego, and an SP. I would venture that some SP's
: get labeled as hotdogs simply because they are more effective and
: supervisors view them as an enigma to be distrusted, a threat to their
: career.
There is a manager here (actually a director of the company!) who originated
from an assembly-language programming background, who would definitely fit
into the "blowhard hotdog" category. He often plays around with the code
but never documents changes or tests anything, with a perception that he
doesn't make mistakes.. and was once overhead saying something like:
"This work is so important that I better do it myself".
--
Stuart Park Melbourne, Australia
Senior Analyst E-mail: stu...@pronto.com.au
Prometheus Software
Stuart Park
: "Chris" <cma...@orangenet.co.uk> wrote:
: >Superprogrammers or sometimes called 'Hereos' , yes I've come across a few
: >guys (and women) who at some point in their career have been called this, I
: >have myself on several occasions too.
: I think you're merging two distinctly different concepts, here. I've heard
: the term "hero" applied to individuals who are the individuals that rescue
: projects in a chaotic organization, aka CMM level 1. Projects succeed or
: fail based on heroic efforts by individuals, instead of being based on
: proper planning.
Another term is "fire-fighter".. i.e. someone who gets all the praise for
battling the flames of an overdue project and completing it, while the
fire-preventers are those that plan the projects carefully and delivering
the completed products on-time and never get noticed.
: A superprogrammer is not necessarily a hero. Superprogrammers will probably
: tend to leave environments where they must become a hero in order for the
: project to succeed. :)
I would personally work for a significantly lower salary, if the workplace
was one where all the managers encouraged quality and good software
processes, and all the programmers and analysts were allowed to plan
work properly.
Michael Stark
>
<snip>
>
> A better comparison for super programmers would be comparative salaries of
> the professional sports people. Then what % difference is there between the
> top and bottom?
>
<snip>
One datapoint -- Michael Jordan makes $30 milllion/yr, the NBA minimum
is about 200,000 dollars.
This is a 60:1 ratio, which seems big until you realize that the ratio
in corporations can easily
exceed 100:1 between the CEO and the lowest paid worker.
I don't expect compensation to EVER reflect the difference in capability
between even the best and
the average programmer, let alone the best and worst.
Mike
--
> Pete McBreen, McBreen.Consulting , Calgary, AB
> email: petem...@acm.org http://www.cadvision.com/roshi
> Using Creativity and Objects for Process Improvement
--
Michael Stark
Goddard Research & Study Fellow
University of Maryland, College Park
e-mail: mst...@cs.umd.edu
phone: (301) 405-2721
"Summer's here, and the time is right, for racing in the streets"
Thomas W. Clay
my chest last week ;) and a process weenie (I LIKE processes! Too
much randomness) I believe that the reviews are beneficial - they take
relatively little time for the author (i.e. other "superprogrammers") and it
can held make novices into "average" developers. You are asking
for trouble if you allow people to say "My code doesn't need review."
I do understand "My code isn't ready yet."
The reviews check many things - not just the accuracy of the
implementation.
Thomas W. Clay
(that's MR. programmer to you!)
Fintan Swanton wrote in message <35D7EFC8...@3b2.com>...
>e_...@yahoo.com wrote:
>
>> gio+van+no+ni+8@tal+star+spam.com (Giovanni 8) wrote:
>>
>> >It's one thing to ask a colleague to take a look at your code;
>> >it's a completely different thing for there to be a forced
>> >formal review.
>>
Thomas W. Clay
>"Chris" <cma...@orangenet.co.uk> wrote:
>
>A superprogrammer is not necessarily a hero. Superprogrammers will
probably
>tend to leave environments where they must become a hero in order for the
>project to succeed. :)
Here here! Well said.
Thomas W. Clay
Superduper programmer
dun...@yc.estec.esa.nlx
> From time to time, I read the statement that there are programmers who
> are 5 or 6 times as productive as teh average professional programmer.
>
> [... snip]
In the various replies to this article, most people have
been concerned with the 'super-programmer' as the guy [or
gal] who can produce code quickly.
I've worked with such people in the past, both 'true
super-programmers' where elegant designs were produced on
paper and everything tested and documented, and those who
were more the 'true super-hacker' churning out code which
solved the problem at hand but was completely unmaintainable
by anyone else (or even by themselves once they'd lost
interest in it). Obviously you would want the first group
on your team, but there is still a need for the second group
when you want one-off, and more importantly, throw-away data
conversion and analysis tools.
I have also worked with a limited number of people whom I
can only describe as 'thorough-' or
'professional-programmers' [*]. Such people may not be able
to dream up new applications or features, but describe the
desired feature to them and they think it all through,
produce design documents, implement, test and document the
code methodically and leave no stone unturned. The 'true
super-programmer' above belongs to this group.
I think that the success of your project would be more
likely if you had a team of 'professional-programmers'
rather than 95% Mr. Averages and 5% super-programmers. In
the first instance you should be looking to educate (or
recruit) your team to be all 'professional-programmers' and
then see whether anyone stands out as a 'true
super-programmer'.
Cheers
Duncan
[*] A colleague of mine, when reviewing a piece of software,
once commented that any programmer could put together a GUI
with flashy dialog boxes, but only the true professional
would make sure that all of the field traversal, hot keys,
and default actions were always available and worked correctly.
Unfortunately there are a lot of people who regard themselves
as 'professional' simply because they are paid for programming.
This is my article, not my employer's, with my opinions and my disclaimer!
--
Duncan Gibson, ESTEC/YCV, Postbus 299, 2200AG Noordwijk, The Netherlands
Tel: +31 71 5654013 Fax: +31 71 5656142 Email: dun...@yc.estec.esa.nlx
To avoid junk email my quoted address is incorrect. Use nl instead of nlx.
paulr
You TeX guys... what a signature. :)
I think you may have something, but to be honest,
someone who can type very quickly often gets burned out
a bit quicker than someone who types a little slower.
I'm personally kind of bad that way when I am
coding, in that I will do 2 or perhaps three compiles
in the time other folks do one. It's a bad habit in
that I could sometimes save time and effort by
thinking it through more throughly. But I get
excited, this stuff is, after all, supposed to be fun.
(Hey, if it isn't fun, why would intelligent, creative
people want to do it?)
I don't encourage it in people that work for me though,
unless I find the kind of person that thrives on it. :)
And it certainly isn't the way to do engineering or design.
It is a implementatin thing all the way.
-Paul
Jeffrey McArthur (jeffmc...@home.com) wrote:
: On Wed, 12 Aug 1998 09:34:27 +0200, "Rommert J. Casimir" <cas...@kub.nl>
: wrote:
: >From time to time, I read the statement that there are programmers who
: >are 5 or 6 times as productive as teh average professional programmer.
: Let me put a completely different spin on this. How fast can the
: programmers type? Programming involves a lot of different things, but one
: of the items often overlooked is the speed at which a person can type.
: Secondly, how comfortable are they with the editor they use to write code?
: If a task is well fully specified, then there may be some visual design, but
: in the end, the programmer has to sit down and write the code. If they can
: type faster, then they can get the idea down faster. If they get the idea
: down faster, there is less time to be distracted by the need to type it.
: A second, but related issue, is how fast the person can change the code they
: have modified. If they are fast with their editor, they can find and change
: code quickly.
: My idea boils down to this, if they person is a fast typist, the attention
: span needed to get the details of the coding down is less, which means they
: are more productive.
: Anyone want to comment on this idea?
: Jeffrey M\kern-.05em\raise.5ex\hbox{\b c}\kern-.05emArthur
: a.k.a. Jeffrey McArthur ATLIS Publishing Services
: http://members.home.net/jeffmcarthur/
Frank A. Adrian
>Another term is "fire-fighter".. i.e. someone who gets all the praise for
>battling the flames of an overdue project and completing it, while the
>fire-preventers are those that plan the projects carefully and delivering
>the completed products on-time and never get noticed.
The concept of a fire fighter is still a good one (and one that deserves
praise, as well), as long as the fire fighter was not also the arsonist who
started the conflagration or the owner who left oily rags by a gas water
heater. There is still something to be said for disaster recovery :-).
But you are correct - fire preventers are not usually held up for high
praise
(after all, no news IS no news).
From a career standpoint, the best place to be is on a project that has
gone sour and be able to turn it around. It's deplorable, but true. Much
of business has always been (and always will be) about being in the right
place at the right time. Sadly, given the current state of software
management,
there will be a lot of "right places" for a considerable time to come...
Ralph Cook
> I have also worked with a limited number of people whom I
> can only describe as 'thorough-' or
> 'professional-programmers' [*]. Such people may not be able
> to dream up new applications or features, but describe the
> desired feature to them and they think it all through,
> produce design documents, implement, test and document the
> code methodically and leave no stone unturned.
Be careful of sounding insulting to those who are thorough or
professional by your definitions. Such people are no less likely
to "dream up new applications or features"; some are better at
it than others, just like some of those who code fast or debug
well or whatever. The above implies that one should *expect*
thorough and/or professional programmers to do less well at
"dreaming up" things, and that's completely without basis.
rc
--
When I do speak for my company, I list my title and use "we".
dun...@yc.estec.esa.nlx
DG> I have also worked with a limited number of people whom I
DG> can only describe as 'thorough-' or
DG> 'professional-programmers' [*]. Such people may not be able
DG> to dream up new applications or features, but describe the
DG> desired feature to them and they think it all through,
DG> produce design documents, implement, test and document the
DG> code methodically and leave no stone unturned.
Ralph Cook replied:
RC> Be careful of sounding insulting to those who are thorough or
RC> professional by your definitions. Such people are no less likely
RC> to "dream up new applications or features"; ... snip ...
Yes, my mistake. I had intended to say that even though *some*
of the 'thorough-' or 'professional-programmers' might not be
able to dream up new applications or features, once the new
feature had been described to them progress would be sure and
steady and the end product would be fully documented, tested,
bug-free, and maintainable. Their strengths lie in software
engineering and not in dreaming up new features. After all,
that's what the people in the marketing department are for :-)
I had one particular person in mind when I wrote the original
article. He admitted that he had little aptitude for dreaming up
new applications. However, you only had to point him at the
problem and it would be thoroughly explored and solved. It was a
pleasure working with him, unlike some others who had thrown
their libraries together in a fraction of the time. Although
they *might* have thought about special cases, they hadn't
bothered to write or test or document the code for the special
cases. And of course, when you came to use their libraries,
these people were often already working on some other project
and it was left you to debug the interface.
Oh yes, I know who I would more rather have in the team.
Cheers
Duncan
Gene Gajewski
Jeffrey C. Dege wrote in message ...
<snip>
>>Diagrams, text, maths and code fragments describing how the implementation
>>will work, a construction oriented document prepared with specific
>>understanding of and reference to the development environment - it is by
>>definition straight forward to implement. It really works too, helps
>>delegation, promotes understanding, raises efficiency, improves schedule
>>predictability blahdy blah.
>
>Do you really believe that the fact that a design is expressed in pretty
>diagrams makes it more likely to work than one expressed as scribbles
>on a bar napkin?
>
>The _only_ certain test of a design is to implement it in code and test
>the result.
>
>I have seen more than one "formal detailed implementation design" that
>had fundamental flaws that were not discovered during extensive review.
>Though in truth, the problems were usually related to misunderstandings
>of how the target environment worked.
The whole concept of formal detailed implementation teeters perilously on
that platform understanding. I don't know how many times I've seen embedded
programmers make fundamental design errors in simple DOS programs created to
test their embedded creations. I could go on....
Chris Cawsey
Giovanni 8 wrote:
> These were errors encountered in implementing the design.
> Are you saying that every paper napkin design you ever did
> turned out to be 100% compatible with the language/system of
> implementation? It's been my experience that that is
> extremely rare. There are always details of the specs,
> the language or the system that foil straight-forward
> implementation of the design after it's been prepared.
I wasn't really saying anything about "paper napkin" designs at all, but
formal detailed implementation designs, that form part of the project's
documentation.
Diagrams, text, maths and code fragments describing how the implementation
will work, a construction oriented document prepared with specific
understanding of and reference to the development environment - it is by
definition straight forward to implement. It really works too, helps
delegation, promotes understanding, raises efficiency, improves schedule
predictability blahdy blah.
Cheers.
Chris Cawsey
cmc@_dlinkgrp_dot_com
Jeffrey C. Dege
Do you really believe that the fact that a design is expressed in pretty
diagrams makes it more likely to work than one expressed as scribbles
on a bar napkin?
The _only_ certain test of a design is to implement it in code and test
the result.
I have seen more than one "formal detailed implementation design" that
had fundamental flaws that were not discovered during extensive review.
Though in truth, the problems were usually related to misunderstandings
of how the target environment worked.
--
You'd think that after all this time
I would have dreamed up a really clever .sig!
Biju Thomas
>
> Do you really believe that the fact that a design is expressed in pretty
> diagrams makes it more likely to work than one expressed as scribbles
> on a bar napkin?
Have anyone done any review of a design on 'paper napkin'? I don't think
so. You may not be able to see anything of the design in the napkin
after some time. So, it is important that the designer makes it a
permanent document, which can be accessed electronically and in printed
form.
Cheers.
Biju Thomas
Chris Cawsey
> Do you really believe that the fact that a design is expressed in pretty
> diagrams makes it more likely to work than one expressed as scribbles
> on a bar napkin?
Sort of. A design that is thought out to its logical conclusion, reviewed
and scheduled for implementation seems more likely to work than informal
unreadable scribbles that get lost between analysis and code. Forgive me
for sounding a bit preachy, but I was hostile to implementation design for
years, often short-changing design to "just get on and write the damn
code". When the system being built became millions of LOCs, and various new
parts had to be designed and written by teams rather than individuals, we
found that implementation design was a way to help achieve architectural
integrity, schedule predictability and defect reduction.
> The _only_ certain test of a design is to implement it in code and test
> the result.
And if it the test fails, debugging the code with reference to a solid
design is cheaper then debugging code which *is* the design.
> I have seen more than one "formal detailed implementation design" that
> had fundamental flaws that were not discovered during extensive review.
> Though in truth, the problems were usually related to misunderstandings
> of how the target environment worked.
We all make mistakes. A known flawed design, that failed during
implementation can be a fed back into the design process for next time, "we
tried that with project X and it didn't work". At least the failure,
referenced back to the design, builds the knowledge of the organisation,
rather than leaving it lost in frustrated code known only to the individual
programmer and maybe one or two of their peers.
Cheers
Chris Cawsey
chris@_jute_dot_demon_co_uk
Stuart Park
: Do you really believe that the fact that a design is expressed in pretty
: diagrams makes it more likely to work than one expressed as scribbles
: on a bar napkin?
scribbles on a bar napkin can never be considered a proper specification..
and you need specifications to have any decent chance of success.
scribbles may make sense when discussed.. but months later when doing the
actual work (and the person who wrote the scribbles may not even be
available for clarification), those scribbles become totally unreadable.
: I have seen more than one "formal detailed implementation design" that
: had fundamental flaws that were not discovered during extensive review.
: Though in truth, the problems were usually related to misunderstandings
: of how the target environment worked.
And I have seen many situations where a "scribble" was supplied, and the project
was delayed for many weeks while the programmer hunted around for information,
trying to decipher the scribbles.
Stuart Park
: The concept of a fire fighter is still a good one (and one that deserves
: praise, as well), as long as the fire fighter was not also the arsonist who
: started the conflagration or the owner who left oily rags by a gas water
: heater. There is still something to be said for disaster recovery :-).
I have seen a few cases in software development where the fire fighter
could also be considered the arsonist.. :-/
John Layman
<01bdce9a$1376f350$0100007f@dcbpccmc2>...
> When the system being built became millions of LOCs, and various new
> parts had to be designed and written by teams rather than individuals, we
> found that implementation design was a way to help achieve architectural
> integrity, schedule predictability and defect reduction.
Here you touch on why the superprogrammer of 1968 might actually be a
liability in 1998. The change in scale of software effort in those thirty
years means that there has been a considerable shift in the skills and
traits needed to do the work.
Thomas W. Clay
>> As a self proclaimed "super-programmer" (I had the big 'S'
>> tattooed on my chest last week ;) and a process weenie (I
>> LIKE processes! Too much randomness) I believe that the
>> reviews are beneficial - they take relatively little time
>> for the author (i.e. other "superprogrammers") and it can
>> held make novices into "average" developers. You are
>> asking for trouble if you allow people to say "My code
>> doesn't need review."
>
>saying, "The code review for X is scheduled for 13:15 in
>conference room C. You must appear with your listings and
>blank review forms BQ-1237-TG7 at that time. Don't be late.
>Your reviewers are A, B & D. Hut hut!"
If it is the software that is controlling some sort of life critical
medical unit, you bet that I want reviews like that.
If a reviewer is not ready for a review, it gets postponed, and
marked in the schedule. If someone doesn't have the time to
review code, then thier schedule should be modified.
>OTOH, asking, "Have you let Fred or Henry check this over?
>I'd like to bounce it by them before you get into coding
>[integration, whatever]." can be beneficial.
Yes, it can, but there is no information tracking here.
Tom Clay