[EM] why 0-99 in range voting

[Jan Kok]

On 11/22/06, RLSuter at aol.com <RLSuter at aol.com> wrote:
> In a message dated 11/22/06 12:11:20 PM Eastern Standard Time,
> abd at lomaxdesign.com writes:
>
> << In meetings, voting on multiple-answer questions is rare. >>
>
> Yes, but why? Because very, very few people -- probably
> less than 1% of U.S. citizens, are familiar with voting
> methods that can handle such questions in satisfactory
> ways.

This is interesting. In my 30+ years of mostly-software engineering
experience, I don't remember a single instance of formally voting (in
the election methods sense, by show of hands or paper ballots) on
anything except where to go for group lunches.

The great majority of decisions made in meetings were of the yes/no or
A/B type. Probably other alternatives had been filtered out by the
engineer or manager before the meeting. In the meeting, the
alternatives would be discussed, and a consensus almost always
emerged. If not, the manager would make a decision, or the decision
would be postponed to allow further investigation of the issue. And if
a decision turned out to be obviously wrong, it was usually possible
to undo it.

A few examples of multiway decisions:

Which bugs to fix (first). Typically, the bugs were given weights,
depending on how frequently they were estimated to occur, the
seriousness (data loss vs. cosmetic defect), whether there was a
"workaround" (a way for the user to avoid the problem), how hard it
would be to fix, etc. Then the highest-weight defects were addressed
first.

Which microprocessor to use in a product. A list of "musts and wants"
would be compiled, and the candidate microprocessors were evaluated
against the must and wants. "Musts" were features that the
microprocessor _had_ to have, to be considered. "Wants" were desirable
features, and were given weights (e.g. 1 to 10). The microprocessor
that met all the musts and got the highest total "wants" rating would
win.

What to buy with expense and capital equipment budgets. Items would be
proposed and priorities assigned to the items. The highest priority
items were bought, as many as would fit into the budget. There were a
couple things about this process that I thought were stupid: 1. "Use
it or lose it." If a project team did not use all of the assigned
budget money in a quarter (three-month budget period), the money was
"lost". There was no way to "put the money in the bank" and use it
later. This encouraged wasting money on relatively unnecessary items,
like new office furniture, fax machines, etc. 2. Seperate expense and
capital equipment budgets (probably due to US tax laws). Sometimes we
would have more of one type of money than the other. Items that cost
more that $1000 were capital equipment, otherwise they were expenses.
So, one could play games. For example, buy a fully loaded file server
if you want to spend capital equipment money. Or, buy the bare bones
file server, and buy the disk drives separately, if you want to spend
expense money.

Where to go for group lunches. We would typically "nominate" 10 or 20
different restaurants, then invent a voting method, and then vote by
show of hands. We invented all kinds of methods... cumulative voting,
limited voting, "one + and one - vote", etc. Sometimes the winning
restaurant was not one that would be expected to win... It was rather
comical.

At any rate, it's interesting that engineers and their managers tend
to avoid traditional voting methods for serious decision making.

Cheers,
- Jan