I am somewhat dyslexic and I don't always read things in the right
order so I read
SLOC/day/programmer
as
SHLOCK/day/programmer
it fits in a negative metric kinda way. Maybe it is a meme we should
unleash on our overlings.
-djl
On Jul 9, 2010, at 12:16 PM, John Zabroski wrote:
Just to be clear,
The foremost experts and definitive source on software metrics --
Fenton and Pfleeger [1] -- do not really support SLOC/day/programmer
as a good metric for productivity. It seems to me (from hearing
reports by others) that most people do not actually read books on
metrics and instead gravitate towards the simplest ones, regardless
of effectiveness.
Usually SLOC/day/programmer is a good way, though, to convince your
boss that a project predicted to be 300,000 lines of brute force
coding cannot be done in a weekend. The argument being you
literally cannot type that fast.
Cheers,
Z-Bo
[1] http://www.amazon.com/Software-Metrics-Norman-E-Fenton/dp/0534956009
On Fri, Jul 9, 2010 at 2:47 PM, Max OrHai <[email protected]> wrote:
Just to clarify, I'm a bit uncomfortable with "productivity" talk
here because it seems too narrow and ill-defined. Productivity of
what exactly? By whom? For whom? To what end? To a specific manager
of a specific project in a specific development phase, these
questions may have specific, meaningful answers. When it comes to
fundamentally rethinking basic tools and practices, I'm not so sure.
Of course, core values must be somewhat vague, to allow them to mesh
with constantly changing circumstances. Personally, I'd rather
strive for "quality" than "productivity". I'm generally suspicious
of premature quantification: just because you can measure something
doesn't make it meaningful!
It seems to me that, as crufty, haphazard, hidebound, etc. as
"software engineering" is today, "software engineering
management" (with its "productivity metrics" such as "source lines
of code per programmer per day") are even worse. We all know code
quality varies wildly between programmers using the exact same sets
of tools. Talent and training contribute enormously. However, I
imagine that everyone on this list can agree that the tools
themselves matter too, even if it's difficult to quantify that
difference precisely.
"Keep it simple" is a widely applicable and successful heuristic. I
see this project as (largely) an experiment in applying that
heuristic to the fairly well-defined category of "creating the
personal computing experience", with a depth and breadth impossible
in the productivity/profit-bound world of commercial software, and a
consistency and quality level impossible in the the traditional open-
source project. It's just an experiment, though. It's research (or,
if you prefer, "intellectual masturbation"). If we already knew the
outcome, it wouldn't be research, would it?
-- Max
On Fri, Jul 9, 2010 at 10:33 AM, David Leibs
<[email protected]> wrote:
for example, is a lot of this added code because:
the programmer has little idea what he was doing, and so just
wildly copy-pasted everywhere and made a big mess?...
has lots of code which is actually beneficial, such as doing error
checking and building abstractions.
similarly, is a piece of code smaller because:
the programmer is good at getting work done in less code?
or because the code is essentially a tangled mess of hacks?
It isn't that the programmer has little idea of what he is doing.
Things just take time to be transformed into an optimal form.
There is a good example from the history from math, and physics that
illustrates the point. Maxwells equations originally applied to a
set of eight equations published by Maxwell in 1865. After that the
number of equations escalated to twenty equations in twenty unknowns
as people struggled with the implications. Maxwell wrestled with
recasting the equations in quaternion form. Time passed. It was all
very ugly. Finally In 1884 Oliver Heaviside recast Maxwell's math
from the then cumbersome form to its modern vector calculus
notation, thereby reducing the twenty equations in twenty unknowns
down to the four differential equations in two unknowns that we all
love and call "Maxwells equations". Heaviside invented the modern
notation giving us the tools to make sense of something very
profound and useful. Good work on hard things takes time plus a lot
of good people that care.
cheers,
-David Leibs
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
