Max, You mention "software engineering management" which reminds me of Tom Gilb's book "Principles of Software Engineering Management" which is still a favorite of mine despite that he replaced it with his more recent "Competitive Engineering". He begins any management exercise by defining six to ten measurable goals, and specifying how the numbers shall be calculated. These are usually quality goals with specific numbers attached.
If "easily learned" is a chosen goal, it is accompanied by selected training and testing procedures to find the numbers which measure progress toward that goal. Inventing ways to meet multiple goals is what he means by the term engineering. Lines of code is a number all right, but it's not often a useful number for the stakeholders paying for the effort. Minutes to complete a specified task after a day of training and practice might more likely be a useful target. Perhaps you'd like to have a few of those quality goals. It often seems that the only real goal for software projects is delivery date since the others all give way in the effort to meet that one. I hate it when that happens. "No time to do it well, but always time to do it over" is a frequent complaint. Richard On Fri, Jul 9, 2010 at 11:47 AM, 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_(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 > > -- Richard Karpinski, Nitpicker extraordinaire 148 Sequoia Circle, Santa Rosa, CA 95401 Home: 707-546-6760 http://nitpicker.pbwiki.com/
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
