A midcourse correction is happening on this posting. It doesn't happen often. But I want to get to the point of "Show, Don't Tell Me," without waiting for the whole inductive example from the chapter of the aforementioned book.
Instead, I'm going to separate out the points from that book for a later discussion.
For now, TheHackerCIO wants to explain the awesome power of showing over telling.
There are a few indicators for seasoned technologists. If you don't back-up like a maniac, then you're still not seasoned. And, if you believe something will work just because someone says it does, or because the manual says so, then you're still wet behind the ears. The principle that captures this is that of "Show, Don't Tell Me."
A perfect illustrative example of this arose this week.
We were working with an unfamiliar device: new to TheHackerCIO, anyway. It was a Magnetic Stripe Card Writer. You know these ubiquitous cards with a magnetic stripe down the back. They follow an ISO 7813 standard of three tracks of data. Our project involves writing on them, which is something I've not done before. It's pretty fun, actually. I printed a picture on the front of a card, and put my name and several numbers of my choosing on one last week.
But this was probably only because I had an experienced engineer helping me out!
As it turns out, the "storybook," as we call the sample program, won't work! The experienced engineer knew what to change, because he's worked on other mag writers. But it simply points out the necessity of calling for a demo.
If you haven't seen a demo from the vendor with your own two eyes, then you've all you can assume you've got is vaporware. Even if you've seen it, you still need to exercise caution about what you conclude, but at least it's a start.
That's why show, don't tell me is so crucial.
And it's also why TheHackerCIO is very dubious about claims found in books and elsewhere. Why is there so little in the way of backing demos for claims about -- well, everything! For instance, in the aforementioned book, the claim is made that:
"Relational databases could also be run as separate servers for different sets of data, effectively sharding the database. While this separates the load, all the sharding has to be controlled by the application which has to keep track of which database server to talk to for each bit of data. Also, we lose any querying, referential integrity, transactions, or consistency controls that cross shards." [reference: p. 8]There is so much in this statement which is questionable, that I don't even know where to begin. You lose querying capabilities cross shards? In DB2 UDB, the database supports creating what are called partitioning keys. These have to be a primary key, but allow the distribution of certain key-ranges on specific backing devices (device placement), thus improving performance. Such a tablespace is called a "partitioned tablespace." And there is no problem querying across the partitions. This is essentially the DB2 support for sharding.
In Wikipedia, sharding is defined as "a horizontal partition in a database ..." And in DB2, table partitioning is exactly that: a horizontal partition, based upon Primary key range. The RDBMS, namely DB2, explicitly supports this: there is no application involvement required! The application doesn't have to be aware of where the partitions are placed.
And, as the link above indicates, there is no problem querying across the partitions. Been there, done that. So I can't imagine what I'm missing about the storybook quote. I can't see any loss of querying, RI, transactions, or consistency controls across partitions in DB2.
Now, maybe this author is thinking about Oracle RAC, or some other DBMS. But the point is, there are other RDBMSs than Oracle or Microsoft Fecal Server! There's a whole world out there.
But I'm an open-minded technologist. Show me the problem you are talking about. Show, don't tell me!!! Put up an example of how you lose these features with your sharding, then I'll learn specifically, and precisely what you mean.
I'm going to be calling more and more for Show Don't Tell.
I Remain,
TheHackerCIO
