From: Gregory Maxwell <gmaxwell@gmail•com>
To: Alan Reiner <etotheipi@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Random order for clients page
Date: Mon, 9 Jul 2012 23:05:44 -0400 [thread overview]
Message-ID: <CAAS2fgT10nf=8TJxYrT4WBNdYUiSU7qQNDTjjbTSuMktn2QVpw@mail.gmail.com> (raw)
In-Reply-To: <4FFB9707.9020307@gmail.com>
On Mon, Jul 9, 2012 at 10:44 PM, Alan Reiner <etotheipi@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
next prev parent reply other threads:[~2012-07-10 3:05 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-09 15:54 Amir Taaki
2012-07-09 16:04 ` Gregory Maxwell
2012-07-09 16:09 ` Amir Taaki
2012-07-09 16:39 ` Stefan Thomas
2012-07-09 16:55 ` Harald Schilly
2012-07-09 17:21 ` Luke-Jr
2012-07-09 17:46 ` Gregory Maxwell
2012-07-09 18:03 ` Alan Reiner
2012-07-09 18:29 ` thomasV1
2012-07-09 18:18 ` Amir Taaki
2012-07-09 18:30 ` Mike Hearn
2012-07-09 22:26 ` Stefan Thomas
2012-07-09 22:37 ` Mike Hearn
2012-07-10 2:36 ` Stefan Thomas
2012-07-10 2:44 ` Alan Reiner
2012-07-10 3:05 ` Gregory Maxwell [this message]
2012-07-10 7:12 ` Wladimir
2012-07-10 9:11 ` Stefan Thomas
2012-07-13 15:20 ` Daniel F
2012-07-09 23:07 ` [Bitcoin-development] Wiki client list (was: Random order for clients page) Luke-Jr
2012-07-09 18:48 ` [Bitcoin-development] Random order for clients page Gregory Maxwell
2012-07-09 20:44 ` Jeff Garzik
2012-07-09 17:33 ` Nils Schneider
2012-07-09 18:24 ` Amir Taaki
2012-07-09 18:54 Jim
2012-07-09 18:57 ` Gregory Maxwell
2012-07-09 19:14 ` Alan Reiner
2012-07-09 20:13 ` Gary Rowe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAS2fgT10nf=8TJxYrT4WBNdYUiSU7qQNDTjjbTSuMktn2QVpw@mail.gmail.com' \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=etotheipi@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox