Re: Oversight and Programmer productivity

Beliavsky wrote:
Over the summer of the average student produced 4,000 lines of code
with some students producing as much at 10, 14 and even 20 thousand
lines. This is an insane amount of code written weather you measure by
time or by money. By some measures this means the students are
anywhere between 5 and 40 times as productive as your 'average'
employed programmer. This code, mind you, was written by a student
who is almost always geographically separated from their mentor by at
least 3 time zones and almost never has a face to face meeting with
their mentor.

Others have already pointed out that it's jumping to a conclusion to
say that more code equals more productivity, and I mostly agree with
that.

But let's suppose that it were the case that the Summer of Code students
really are more productive than paid programmers. Is a hands-off style of
management really the cause?

I'd like to suggest that it could perhaps be not simply the level of
day-to-day involvement that management has but a difference in the
level of motivation -- and possibly even more important, inspiration --
that the students have in their work.

If this is the case, several factors could be causing it:
(1) Students have more of a need to prove themselves. They have
less experience, and this may be their only opportunity, ever,
to impress someone at Google.
(2) Students are younger and have fewer responsibilities and more
energy (physically) than an experienced career programmer, who
might have to devote some of their time to taking care of kids
or mowing the lawn.
(3) Students are more likely to still have the sense of wonder
and discovery about programming than some experienced career
programmers will (if only because it is still new to the
students).
(4) Students are not likely to view the problem in project management
terms where the number of hours of coding must be minimized and
the quality / completeness of the solution is secondary; instead,
students will tend to view the project as an end unto itself
and will devote whatever resources necessary to produce something
they're pleased with.
(5) $4500 is a LOT of money to many college students. :-)

Regarding #4, I've been in situations where, quite understandably, we
slashed features from a development project in order to cut the time
necessary to complete it. This seems like the practical thing to do,
and probably it really is a lot of the time, but I wonder if in some
other cases it isn't a false economy. I wonder if when a group makes
the design decisions necessary to reduce work, they aren't sometimes
cutting the amount of code by 50% and the joy of working on the project
by 90%. If you can assume that lines of (useful, quality) working code
produced per unit of time is proportional to joy experienced while coding,
then doubling the lines of coded needed but making it 10 times more joyful
to write the code would have you finished much faster.

Case in point, I once worked at a shop where a team of programmers was
porting a set of applications from one GUI toolkit to another. The
customer had clearly said that we were not to rewrite the applications.
Obviously the motivation was to reduce the amount of work required.
One programmer was in charge of porting a small text editor app.
After days (weeks?) of slogging through and trying to port the existing
code, he apparently had a "screw it" moment and decided to rewrite it
anyway. He quickly finished it and as a result came in well ahead of
schedule.

I guess the point here is two-fold:

(1) When management says "do not do it *this* way, because that takes
longer", the "that takes longer" part is sometimes an assumption.
But the "do not do it *this* way" part definitely is a constraint,
and so removes possible paths to a solution from the programmer's
set of options. So in some cases, management's attempts to speed
things along can actually create constraints that slow things down.
In that sense, management involvement can sometimes reduce
programmer productivity.

(2) Although the ideal programmer can do any task at maximum
productivity regardless of whether they enjoy it, in the real
world people are more motivated when they are doing something
they enjoy and producing a product they'll be proud of. To the
extent that you take that away from them, you take away part of
their motivation. Organizations should not be set up to cater to
prima donna programmers, but good management realizes that people
are much more motivated when they have the opportunity to be
involved in something great and worthwhile than when they are
involved in something mediocre and "just good enough". Voltaire
is correct that "perfection is the enemy of good", but at the
same time, mediocrity is the enemy of motivation.

I picture students (*some* students, like those working on Summer of
Code) as being at the confluence of the good sides of both #1 and #2.
They're free to do it how they want because those are the parameters
of Summer of Code, and they're motivated to do something great because
(a) they're doing it for google (and glory and fame), and (b) they're
contributing to an open-source project whose raison d'etre is (typically)
to cause good code to come into existence.

Well, that's enough rambling for me for now. :-)

- Logan
.

Relevant Pages

  • Re: Thou shalt have no other gods before the ANSI C standard
    ... >>like to provide a reference, but this was almost 30 years go). ... >>measured the productivity of their CS students on a standardized ... >>productivity rates across the student population. ... One lump was small, < 20%, but represented ...
    (sci.crypt)
  • Re: Thou shalt have no other gods before the ANSI C standard
    ... >>measured the productivity of their CS students on a standardized ... >>distribution of the productivity ratios, but I don't remember what it ... humming and tapping their feet all day. ... on the shoulder and asking them to please remove their headphones. ...
    (sci.crypt)
  • Re: Thou shalt have no other gods before the ANSI C standard
    ... >> like to provide a reference, but this was almost 30 years go). ... >> measured the productivity of their CS students on a standardized ... >> productivity rates across the student population. ... Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ ...
    (sci.crypt)
  • Re: Thou shalt have no other gods before the ANSI C standard
    ... >>like to provide a reference, but this was almost 30 years go). ... >>measured the productivity of their CS students on a standardized ... >>productivity rates across the student population. ... Swearing isn't a good metric, ...
    (sci.crypt)
  • Re: Trying to use STRING
    ... think about iterative control than other loop structures do. ... students comprehend better. ... Are you suggesting that a modern COBOL programmer would be ... built by using subscripts to copy the characters from ...
    (comp.lang.cobol)