One thing that is often frustrating for software developers is naming things.
The terms (especially those inside the code, and IIRC "punishment" is a function name, not a design concept) have to mean something to the developers themselves, and yet, we'd be better off with meaningless terms when talking to people outside the development community. I wouldn't claim to be a BOINC developer, but I've been coding long enough to have seen the phenomenon many times. The purpose here is to protect the project from one broken host that quickly returns trash, and as a result is constantly downloading work. Left to an extreme case, that one host may actual starve others that are doing useful work. The problem with "meaningful" names is that there is always someone who wants to take the metaphorical "punishment" and take it under the "Greco-Roman-Judeo-Christian-Anglo-American" meaning. I might have used the term "rate-limiting" or "throttling" but even those have the risk of being taken too literally. I'd mean "throttle" in the sense of a throttle in a car, controlling speed, and someone would take it to mean grabbing someone by the throat and squeezing to block their windpipe, and now we're back to "punishment." People always seem to try on every definition of a word, and pick the one that is the most offensive. Maybe the concept should be called "qwert" since that's easy to type and does not mean anything -- but first, we'd best check as many dictionaries as possible, lest it mean something in some obscure language. Sorry for getting on my soapbox. We now return you to the technical discussion, already in progress. On 5/26/2010 11:15 AM, Charles Elliott wrote: > If you outline the book Campbell, J. P., M. D. Dunnette, et al. (1970). > Managerial Behavior, Performance, and Effectiveness. New York, McGraw-Hill, > you will find that all 19 chapters fit neatly into 4 categories: Selection, > motivation, training and development, and psychology. The words punishment, > punish, punishing, etc., do not appear in the chapter titles or in the > index. This is in line with our Greco-Roman-Judeo-Christian-Anglo-American > heritage and is congruent with the distinction between the Old and New > Testaments: In the former God wiped out the population with a flood, visited > people with plagues, and turned people into pillars of salt when they > sinned, whereas in the latter he sends his son(s) to show people how to > solve their problems. > > If you go through a pending credit list you will probably find several > instances where users have simply abandoned s...@home leaving hundreds if > not thousands of work units unprocessed. De-select them; if they come back > after a month or two, fine. If they don't, that is fine too. The same > treatment should be accorded to the person who day after day returns nothing > but errors. I don't see any other way to protect the system against people > who intend harm or simply don't care. > > As for people who error-out hundreds of work units, they have a problem, and > punishing them is not going to fix it nor earn you any goodwill. A message > telling them that the problem is almost certainly due to a bad video card, > bad memory, or overclocking and giving a URL to a page describing basic > hardware debugging techniques (e.g., substitute a known-good part, run a > diagnostic such as Memtest86+, reduce the bus frequency, etc.) is far more > helpful and more in line with our culture. > > We need to motivate people who do well by, say, giving extra credit for > consistency, rather than punishing them for their mistakes, which they > probably already know are stupid, or for part failure over which they may > have no control. > > Charles Elliott > > > _______________________________________________ > boinc_dev mailing list > [email protected] > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. > _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
