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 v <http://en.wikipedia.org/wiki/Vector_%28geometric%29>ector >> 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
