Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2012-07-10 📝 Original message:On Mon, Jul 9, 2012 at ...
📅 Original date posted:2012-07-10
📝 Original message:On Mon, Jul 9, 2012 at 10:44 PM, Alan Reiner <etotheipi at gmail.com> wrote:
> What a feature matrix is good at though is it allows you to very quickly
> find the specific feature or general criteria you're looking for without
> reading through all of the text. So it might be a useful addition maybe
> not on Bitcoin.org, but certainly on the wiki.
I'm generally not a fan of feature matrixes, they encourage "checkbox
decision making"— which is seldom very good for the decider, though
it's much loved by the marketing department that puts together the
matrix. But just becase something is loved by marketing departments
for its ability to set the agenda in variously biased ways doesn't
mean its a great thing to emulate.
Take the matrix Luke linked to for example[1]. Now imagine that we
tunnel MyBitcoin from a year ago and drop it into that table. It
would have every light green, except 'encryption' (which wouldn't have
been green for bitcoin-qt then either). It would basically be the
dominant option by the matrix comparison, and this is without any
lobbying to get MyBitcoin specific features (like their shopping chart
interface) added, not to mention the "_vanishes with everyone's
money_" feature.
I don't think I'm being unreasonable to say that if you could drop in
something that retrospectively cost people a lot into your decision
matrix and it comes out on top you're doing something wrong.
In tables like this significant differences like "a remote hacker can
rob you" get reduced to equal comparison with "chrome spoiler", and
it further biases development motivations towards features that make
nice bullets (even if they're seldom used) vs important infrastructure
which may invisibly improve usage every day or keeps the network
secure and worth having. "Of course I want the fastest startup! Why
would I choose anything else?" "What do you mean all my bitcoin is
gone because the four remaining full nodes were taken over and reorged
it all?"
I wouldn't expect any really important features which don't have
complicated compromises attached to them to be omitted from all
clients for all that long.
Basically matrixes make bad decision making fast, and by making it
fast it's more attractive than careful decision making that always
takes time. The text is nice because it contextualizes the complete
feature set and helps you understand why different clients exist, what
problems they attempt to solve, and what compromises they make. ...
without making the unrealistic demand of the user they they know how
to fairly weigh the value of technical and sometimes subtle issues.
[1] https://en.bitcoin.it/wiki/Clients
📝 Original message:On Mon, Jul 9, 2012 at 10:44 PM, Alan Reiner <etotheipi at gmail.com> wrote:
> What a feature matrix is good at though is it allows you to very quickly
> find the specific feature or general criteria you're looking for without
> reading through all of the text. So it might be a useful addition maybe
> not on Bitcoin.org, but certainly on the wiki.
I'm generally not a fan of feature matrixes, they encourage "checkbox
decision making"— which is seldom very good for the decider, though
it's much loved by the marketing department that puts together the
matrix. But just becase something is loved by marketing departments
for its ability to set the agenda in variously biased ways doesn't
mean its a great thing to emulate.
Take the matrix Luke linked to for example[1]. Now imagine that we
tunnel MyBitcoin from a year ago and drop it into that table. It
would have every light green, except 'encryption' (which wouldn't have
been green for bitcoin-qt then either). It would basically be the
dominant option by the matrix comparison, and this is without any
lobbying to get MyBitcoin specific features (like their shopping chart
interface) added, not to mention the "_vanishes with everyone's
money_" feature.
I don't think I'm being unreasonable to say that if you could drop in
something that retrospectively cost people a lot into your decision
matrix and it comes out on top you're doing something wrong.
In tables like this significant differences like "a remote hacker can
rob you" get reduced to equal comparison with "chrome spoiler", and
it further biases development motivations towards features that make
nice bullets (even if they're seldom used) vs important infrastructure
which may invisibly improve usage every day or keeps the network
secure and worth having. "Of course I want the fastest startup! Why
would I choose anything else?" "What do you mean all my bitcoin is
gone because the four remaining full nodes were taken over and reorged
it all?"
I wouldn't expect any really important features which don't have
complicated compromises attached to them to be omitted from all
clients for all that long.
Basically matrixes make bad decision making fast, and by making it
fast it's more attractive than careful decision making that always
takes time. The text is nice because it contextualizes the complete
feature set and helps you understand why different clients exist, what
problems they attempt to solve, and what compromises they make. ...
without making the unrealistic demand of the user they they know how
to fairly weigh the value of technical and sometimes subtle issues.
[1] https://en.bitcoin.it/wiki/Clients