Are U.S. programmers slackers?
Frank McKenney
When I first stumbled into this thread, then read the CNN article,
http://www.cnn.com/TECH/computing/9904/15/slacker.idg/
I was concerned because the conclusions didn't seem warrnated by the
evidence presented. Admittedly, this story is only a few paragraphs, so
CNN didn't really have the space to comment on the methodology used, but
there did seem to be a rather big leap from "U.S. programmers surveyed
produce fewer LOCs (lines of code) than non-U.S. programmers surveyed"
all the way to "fat and happy" and "complacent".
I was also bothered by the way those quoted spent their time providing
explanations for and justifications of the conclusion rather than
questioning the conclusion itself. I wish I could remember who said
that the person who gets to frame the questions controls the debate, but
it certainly seems to apply here. Even Ed Yourdon, who has studied the
software industry for many years, apparently bought into the "fewer LOCs
means less productivity" assumption, and simply tried to explain it as
"more likely the result of job burnout from putting in 70-hour workweeks
to meet business pressures and deliver IT projects faster".
So I went wandering the 'web to see if I could locate the original
survey. At least I'd know what to attribute to whom, which can be
difficult if all one has is CNN's interpretation... of a Computerworld
article... _describing_ the study <grin>.
I didn't find it, but I did run across another 'web page by Mr. Rubin:
Top 10 Mistakes in IT Measurements
http://www.hrubin.com/headline/mistake.html
The number one Mistake?
1) Betting the measurement program on a single metric
Later on, we also have these quotes:
"At the simplest level, there is no standard for measuring IT
performance."
"Productivity measurement or performance measurement can easily fall
into the trap of looking at output per unit input. In the world of
applications development and support it is far too easy to measure
applications related commodities such as lines of code or function
points."
--
At this point, I'm hopelessly confused. Why would someone who was
intelligent enough (e.g. who generally seems to share my prej... er,
opinions (;-)) to write the above conduct a study of productivity that
(based on reports) seems to have been based entirely on LOCs?
Can anyone help me cut through the fog here? A pointer to the original
study might help clear things up a little, but I haven't had much luck
with AltaVista.
Thanks...
Doug
Frank McKenney <frank_m...@mindspring.com> wrote:
>
>When I first stumbled into this thread, then read the CNN article,
>
> http://www.cnn.com/TECH/computing/9904/15/slacker.idg/
...
>So I went wandering the 'web to see if I could locate the original
>survey. At least I'd know what to attribute to whom, which can be
>difficult if all one has is CNN's interpretation... of a Computerworld
>article... _describing_ the study <grin>.
>
>I didn't find it, but I did run across another 'web page by Mr. Rubin:
>
> Top 10 Mistakes in IT Measurements
> http://www.hrubin.com/headline/mistake.html
>
>The number one Mistake?
>
> 1) Betting the measurement program on a single metric
There's nothing wrong with measuring gross output. However, it falls on
it's face when you ask about the *quality* of the code. How about some
metric like:
LOC
---
(Priority1Bugs)^2 * (Priority2Bugs)
Where P1 bugs either crash the system, lose user data, or some other
*really bad thing*. P2 bugs are *less severe*, but at the least cause
users to waste their time. I've read somewhere that you typically get
1 bug per 10K LOC, but YMMV.
doug
sirwi...@my-dejanews.com
do...@halcyon.com (Doug) wrote:
> In article <7fnjln$pim$1...@nntp1.atl.mindspring.net>,
> Frank McKenney <frank_m...@mindspring.com> wrote:
> >
> >When I first stumbled into this thread, then read the CNN article,
> >
> > http://www.cnn.com/TECH/computing/9904/15/slacker.idg/
>
> ...
>
> >So I went wandering the 'web to see if I could locate the original
> >survey. At least I'd know what to attribute to whom, which can be
> >difficult if all one has is CNN's interpretation... of a Computerworld
> >article... _describing_ the study <grin>.
> >
> >I didn't find it, but I did run across another 'web page by Mr. Rubin:
> >
> > Top 10 Mistakes in IT Measurements
> > http://www.hrubin.com/headline/mistake.html
> >
> >The number one Mistake?
> >
> > 1) Betting the measurement program on a single metric
>
> There's nothing wrong with measuring gross output.
Sure there is. A programmer is not a coder, sitting behind a terminal
hammering out lines of code. A programmer is an engineer with many more
responsibilities than this. He must research the problem domain. He must
design systems. He must document everything. He must attend meetings. He
must handle user inquiries (this includes but goes beyond tech support). He
must learn new techonologies. I could go on and on adding to this list. Many
of the things on the list already have no "gross output", much less a single
metric one can apply.
> However, it falls on
> it's face when you ask about the *quality* of the code. How about some
> metric like:
>
> LOC
> ---
> (Priority1Bugs)^2 * (Priority2Bugs)
>
> Where P1 bugs either crash the system, lose user data, or some other
> *really bad thing*. P2 bugs are *less severe*, but at the least cause
> users to waste their time. I've read somewhere that you typically get
> 1 bug per 10K LOC, but YMMV.
This metric is useful for measuring the quality of the code, not for measuring
the productiveness of the programmer. That's a very different thing.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
paulb...@my-dejanews.com
frank_m...@mindspring.com wrote:
<snip background>
>
> At this point, I'm hopelessly confused. Why would someone who was
> intelligent enough (e.g. who generally seems to share my prej... er,
> opinions (;-)) to write the above conduct a study of productivity that
> (based on reports) seems to have been based entirely on LOCs?
>
and get their name on the cover of magazines like ComputerWorld.
> Can anyone help me cut through the fog here?
There's really nothing to cut through. The article was fatally flawed. It
was worse than useless (it was misleading).
It was based on the use of a statistic (average instead of median) which is
sensitive to outliers and of course they did not remove outliers; and it was
based on a measure of code size rather than a measure of functionality even
though it talked about "productivity" as if it was from the user's view.
Either of these would have reversed the conclusion the article reached.
>A pointer to the original
> study might help clear things up a little, but I haven't had much luck
> with AltaVista.
You can no doubt purchase the original study, for a tidy sum, from the
MetaGroup web site.
Marcus Vinicius
>At this point, I'm hopelessly confused. Why would someone who was
>intelligent enough (e.g. who generally seems to share my prej... er,
>opinions (;-)) to write the above conduct a study of productivity that
>(based on reports) seems to have been based entirely on LOCs?
>
>with AltaVista.
They original is available at www.metagroup.com....but you have to pay $5,000
to get it.
There are several things you are missing.....
1. There results of the study were preordained. Had there been contrary
results they never would have been reported.
2. Dr. Rubin's biography, contains no indication that he has *EVER* worked on
a real, large scale, development project. It's very possible he has no concept
of what really goes on in software develppment.
3. One of the problems in IS is the many senior managers have never risen
through the ranks in IS. The good manager can manage anything philosophy is in
force. Consequently, the target audience for the study is unlikely to know
the difference.
4. The "ZYX Group"s in the industry analysis business live by putting out
prattle like this. Sensational material sells better than mundane. Most large
IS organizations spend at least 5 figures a year on this nonsense. If you were
ever to get your hands on some of the Gartner Group material read by senior
managers you would be on the floor laughing after reading it.
5. Measurement by LOC is not the problem here. I doubt that Dr. Rubin's number
have any relationship to reality. Last year (using the same numbers) he was
taking about how US programmer productivity doubled within the course of a
year. How many of you people out there realy believe that? The Meta Group put
out another report earlier this year about how IS organizations were doing
more with fewer people. Now they put out a report that says US programmers are
lazy.
Again, it's just trying to sell newspapers.
On the surface it would seem that these two reports are contradictory. Au
contraire mon frere. The earlier report provides material for the IS
management to take to their management to show how effective IS management is.
The second allows them to show that their problems are due to lazy
programmers, not poor management.
John - N8086N
Wise man says "Never use a bank with the initials F. U."
-------------------------------------------
Are you interested in a professional society or
guild for programmers? Want to fight section 1706?
See www.programmersguild.org
Newsgroup: us.issues.occupations.computer-programmers
EMail Address:
_m-i-a-n-o_@_c_o_l_o_s_s_e_u_m_b_u_i_l_d_e_r_s._c_o_m_
Jonathan Eric Miller
are located in the US versus elsewhere? Not to bad mouth other countries,
but, this industry wouldn't be where it is today if it weren't for companies
and their programmers that are located here in the US.
Jon
Frank McKenney <frank_m...@mindspring.com> wrote in message
7fnjln$pim$1...@nntp1.atl.mindspring.net...
>
>When I first stumbled into this thread, then read the CNN article,
>
> http://www.cnn.com/TECH/computing/9904/15/slacker.idg/
>
>I was concerned because the conclusions didn't seem warrnated by the
>evidence presented. Admittedly, this story is only a few paragraphs, so
>CNN didn't really have the space to comment on the methodology used, but
>there did seem to be a rather big leap from "U.S. programmers surveyed
>produce fewer LOCs (lines of code) than non-U.S. programmers surveyed"
>all the way to "fat and happy" and "complacent".
>
>I was also bothered by the way those quoted spent their time providing
>explanations for and justifications of the conclusion rather than
>questioning the conclusion itself. I wish I could remember who said
>that the person who gets to frame the questions controls the debate, but
>it certainly seems to apply here. Even Ed Yourdon, who has studied the
>software industry for many years, apparently bought into the "fewer LOCs
>means less productivity" assumption, and simply tried to explain it as
>"more likely the result of job burnout from putting in 70-hour workweeks
>to meet business pressures and deliver IT projects faster".
>
>So I went wandering the 'web to see if I could locate the original
>survey. At least I'd know what to attribute to whom, which can be
>difficult if all one has is CNN's interpretation... of a Computerworld
>article... _describing_ the study <grin>.
>
>I didn't find it, but I did run across another 'web page by Mr. Rubin:
>
> Top 10 Mistakes in IT Measurements
> http://www.hrubin.com/headline/mistake.html
>
>The number one Mistake?
>
> 1) Betting the measurement program on a single metric
>
>Later on, we also have these quotes:
>
> "At the simplest level, there is no standard for measuring IT
> performance."
>
> "Productivity measurement or performance measurement can easily fall
> into the trap of looking at output per unit input. In the world of
> applications development and support it is far too easy to measure
> applications related commodities such as lines of code or function
> points."
>
>--
>
>At this point, I'm hopelessly confused. Why would someone who was
>intelligent enough (e.g. who generally seems to share my prej... er,
>opinions (;-)) to write the above conduct a study of productivity that
>(based on reports) seems to have been based entirely on LOCs?
>
>Can anyone help me cut through the fog here? A pointer to the original
>study might help clear things up a little, but I haven't had much luck
>with AltaVista.
>
>Thanks...
>
>
>
Scott P. Duncan
> I can think of one reason: they wanted a soundbite in order to get publicity
> and get their name on the cover of magazines like ComputerWorld.
And it would seem that the quality of information in a ComputerWorld
article has not improved one bit in over 20 years. In the 70s I worked for
a company where our marketing department got customers to submit "articles"
about the use of our products which were largely written by the marketing
department of our company. ComputerWorld and other "trade" magazines
are thinly disguised advertising for vendors and special interests which is
why "if you qualify," i.e., it looks like you control a budget of some kind,
the subscriptions are usually free.
--
Scott P. Duncan
SoftQual Consulting http://www.mindspring.com/~softqual/
Marcus Vinicius
>Let's put it this way. How many of the top software development companies
>are located in the US versus elsewhere? Not to bad mouth other countries,
>but, this industry wouldn't be where it is today if it weren't for companies
>and their programmers that are located here in the US.
One thing should be pointed out. The study only compared IS departments. If
you have ever worked in both an IS organization and a software development
organization you would know why the US is at the top of the software
development game and why IS is so far behind what is going in in software
development.
Since IS and Software development companies draw from the same labor pool,
there is another conclusion that one could draw from Dr. Rubin's results.
Unfortunately it is one that would prevent corporation from paying $5,000 a
pop for copies.
anthony classick
Doug
<sirwi...@my-dejanews.com> wrote:
>In article <7fnnro$cu8$1...@halcyon.com>,
> do...@halcyon.com (Doug) wrote:
>> In article <7fnjln$pim$1...@nntp1.atl.mindspring.net>,
>> Frank McKenney <frank_m...@mindspring.com> wrote:
>> >
>> There's nothing wrong with measuring gross output.
>
>Sure there is. A programmer is not a coder, sitting behind a terminal
>hammering out lines of code. A programmer is an engineer with many more
>responsibilities than this. He must research the problem domain. He must
>design systems. He must document everything. He must attend meetings. He
>must handle user inquiries (this includes but goes beyond tech support). He
>must learn new techonologies. I could go on and on adding to this list. Many
>of the things on the list already have no "gross output", much less a single
>metric one can apply.
>
>> However, it falls on
>> it's face when you ask about the *quality* of the code. How about some
>> metric like:
>>
>> LOC
>> ---
>> (Priority1Bugs)^2 * (Priority2Bugs)
>>
>> Where P1 bugs either crash the system, lose user data, or some other
>> *really bad thing*. P2 bugs are *less severe*, but at the least cause
>> users to waste their time. I've read somewhere that you typically get
>> 1 bug per 10K LOC, but YMMV.
>
>This metric is useful for measuring the quality of the code, not for measuring
>the productiveness of the programmer. That's a very different thing.
So what the hell is productivity if not quality and quantity?
doug
sirwi...@my-dejanews.com
do...@halcyon.com (Doug) wrote:
> In article <7fnuo2$2ve$1...@nnrp1.dejanews.com>,
> <sirwi...@my-dejanews.com> wrote:
> >In article <7fnnro$cu8$1...@halcyon.com>,
measuring
> >the productiveness of the programmer. That's a very different thing.
>
> So what the hell is productivity if not quality and quantity?
*shakes head* Where above do I mention *quantity*. Your metric is solely a
metric of quality, not of quantity, and thus not of productivity.
Marcus Vinicius
>So what the hell is productivity if not quality and quantity?
If the number of lines of code produced proportional to the quanitity of
software software?
It's certainly a qualitative measurement, but how precise? (Not very)
bio...@erols.com
>
> One thing should be pointed out. The study only compared IS departments. If
> you have ever worked in both an IS organization and a software development
> organization you would know why the US is at the top of the software
> development game and why IS is so far behind what is going in in software
> development.
>
> Since IS and Software development companies draw from the same labor pool,
> there is another conclusion that one could draw from Dr. Rubin's results.
> Unfortunately it is one that would prevent corporation from paying $5,000 a
> pop for copies.
>
Having worked for vendors, consulting companies, and in-house IS
organizations, this one is easy. IS departments recruit from the bottom
of the barrel. They generally have one alpha (who everyone else in the
shop wonders why this person is working for the in-house,) and one
hundred omegas (who struggle to build the simplest systems.) A person
does not have to be a genius to know why they recruit from the bottom of
the barrel. They are tight with the $$$.
Additionally, I have found the people in these organizations to be quite
different in professional orientation. Developers with vendors tend to
be hard-core, bits and bytes people. Who know their tool-set very well,
and have a deep understanding of what they are doing (i.e., they can
work there way through the toughest problems.) Consultants/Contractors
tend to have a broad understanding of tools, technology, and domains.
What they lack in technical expertise they make up for in interpersonal
and business skills. In-house people tend to be the weakest
technically, but tend to have a deep understanding of the business
process (it stands to reason because a large percentage of their
personnel are OJT, re-treads from functional positions.) Now, there are
always exceptions to the above descriptions, but for the most part this
has been my personal experience.
Mark
Gulchi
Yeah, you're definitely about as on-the-mark as anybody will ever get.
Marcus Vinicius
>Marcus Vinicius wrote:
>>
>> One thing should be pointed out. The study only compared IS departments. If
>> you have ever worked in both an IS organization and a software development
>> organization you would know why the US is at the top of the software
>> development game and why IS is so far behind what is going in in software
>> development.
>>
>> Since IS and Software development companies draw from the same labor pool,
>> there is another conclusion that one could draw from Dr. Rubin's results.
>> Unfortunately it is one that would prevent corporation from paying $5,000 a
>> pop for copies.
>>
>
>Having worked for vendors, consulting companies, and in-house IS
>organizations, this one is easy. IS departments recruit from the bottom
>of the barrel. They generally have one alpha (who everyone else in the
>shop wonders why this person is working for the in-house,) and one
>hundred omegas (who struggle to build the simplest systems.) A person
>does not have to be a genius to know why they recruit from the bottom of
>the barrel. They are tight with the $$$.
The alpha is usually a consultant. :-)
Wade Warrens
Frank McKenney wrote:
>
> When I first stumbled into this thread, then read the CNN article,
>
> http://www.cnn.com/TECH/computing/9904/15/slacker.idg/
>
> I was concerned because the conclusions didn't seem warrnated by the
> evidence presented. Admittedly, this story is only a few paragraphs, so
> CNN didn't really have the space to comment on the methodology used, but
> there did seem to be a rather big leap from "U.S. programmers surveyed
> produce fewer LOCs (lines of code) than non-U.S. programmers surveyed"
> all the way to "fat and happy" and "complacent".
<snip>
From the referenced page:
The study, released here last week, was prepared by researcher
Howard Rubin for Meta Group Inc. in Stamford, Conn. Using
a standard measure of IT productivity based on the number of
lines of code developed by a programmer per year, the study
pegged U.S. programmer productivity at an average of 7,700
lines of code, compared with 16,700 lines for non-U.S.
programmers.
Well, I can make unsubstantiated assertions just as well as the
expensive folks:
a) Non-U.S. programmers are all programming in assembler, while we in
the U.S.
program only in Excel macros. Therefore, considering "function
points per year",
we are actually 37.176 times MORE productive! Yippee!
b) No, that's silly. We all use C. However, U.S. programmers are so
supremely
elegant in their coding that we can implement the same functionality
in only
one-fourth the amount of code. So, we're TWICE as productive! Beer
call!
c) No, we're really not all that elegant. But wait, U.S. programmers
have
been able to convince their managers that 90% of everything is crap,
so we
only implment the 10% that is actually useful. So, 7700/(0.10*16700)
=
4.6108 times MORE productive! Pay raises for everyone!
--wade