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_(geometric)>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
