Farewell, Paper Books

We've been doing some clearing out at Speirs Towers. Since Carolyn and I are now both Kindle owners, we worked out a few rules for whittling down our stock of books.

  • Rule 1: If it's a rare or very expensive book, keep it.
  • Rule 2: if it's available on Kindle, dispose of it - with the understanding that, if the book is ever wanted again, we'll re-buy electronically.
  • Rule 3: if the book has been superseded by the web or an iOS app, dispose of it.
  • Rule 4: If the book is still relevant, not available electronically and still interesting, keep it.

We only found two books that were sufficiently rare or expensive as to meet Rule 1. We disposed of more than half a bookshelf under Rules 2 and 3. The majority of the books that survived under Rule 4 were kids books that don't - yet - work well electronically (although the iBooks store is making big moves in that direction now).

I'm not much of one for making predictions. I usually suck at predicting in the short term because I underestimate how long it takes people to change their mind. I do better in the medium to long term and one prediction that see coming true is the idea that ebooks will eventually become the default form of accessing long-form prose. I don't think I can say exactly when but, if I can convince such an avid reader as my wife to go through a process like the above, I know the day is coming.

On eBook Pricing

My friend Nik Fletcher nails a good chunk of my dissatisfaction with the ebook marketplace - and I say that as someone who, this very day, broke down and purchased an actual Kindle to go with his iPad.

You win, Bezos, you magnificent capitalist.

Philip Jones then followed up on FutureBook.net by wondering if Nik was being a little "hysterical" with the word gouging. Since that word really came from Nik quoting a tweet of mine, I thought I should chime in.

Let me make this very clear: I know absolutely nothing about publishing. I don't know how deals are structured, I don't know about advances or geographical rights or anything. All I know is that I'm being offered one package of words in, usually, three formats - hardback, paperback and ebook - at three different prices.

In The Design of Everyday Things Donald Norman famously wrote about the disconnect between the user's mental model of how something works and how it actually works. I think I have this problem with ebooks.

Here's how I think of it:

I made these numbers up and I have no idea if the relative proportions of these blocks are correct in any way. In a sense, that's not the point. What I'm expressing here is how I think about the value proposition when presented with three different ways to read the same book.

The thing that rubs me the wrong way with being asked to pay a premium for an ebook is that, thanks to DRM, a publisher gets to sell a copy that can never ever be resold. I think that enforced reduction to zero of the resale value of a book should be reflected in the purchase price - particularly for higher-end titles such as reference books.

The graph above shows how I think of ebooks and my buying behaviour reflects that. I don't see ebooks as luxury items. I don't see how pricing ebooks above hardback prices is defensible when there has been no material to physically construct and ship. I particularly resent that pricing structure when so many ebooks that I purchase have obvious OCR errors or truly awful typography.

Neither do I see ebooks as having no value. People gots to get paid and I'm happy to pay for ebooks - I have never pirated a book. I just see premium pricing on ebooks as someone, somewhere taking a fat profit from ebook early adopters on the basis that those users are keen on books.

So what happens if I feel I'm being ripped off for the ebook? Do I buy the paper version? No. I just move to the next item in my list of "books that sounded interesting". Maybe I'll come back to yours but that list contains, at current rates of consumption, about two years worth of reading. It'll be a while until I get back to you.

I don't care and don't want to have to care about the internal structure of your industry and the value chain and who pays for what when. If it doesn't feel like a good deal, then no deal. All this says to me is "we think you're a schmuck":

I'm not unsympathetic to people trying to make a living in book writing or publishing. I merely note that any value proposition that includes within it something about "you, the customer, need to understand our cost structures and pressures" sadly contains the seeds of its own destruction.

Caring For The Code

I recently picked up the new book 97 Things Every Programmer Should Know edited by Kevlin Henney and published by O'Reilly.

In the currently-fashionable ADHD-afflicted style, It's a collection of 97 short essays on computer programming. I gently mock the concept but books laid out in this way are absolutely perfect for reading on an iPhone.

Anyway, I'm about a quarter of the way through and enjoying it a lot. The stand-out essay in the first quarter is by Robert C. Martin, entitled "The Boy Scout Rule". Here's an excerpt:

THE BOY SCOUTS HAVE A RULE: “Always leave the campground cleaner than you found it.” If you find a mess on the ground, you clean it up regardless of who might have made it. You intentionally improve the environment for the next group of campers.

What if we followed a similar rule in our code: “Always check a module in cleaner than when you checked it out”? Regardless of who the original author was, what if we always made some effort, no matter how small, to improve the module? What would be the result?

I think if we all followed that simple rule, we would see the end of the relentless deterioration of our software systems. Instead, our systems would gradually get better and better as they evolved. We would also see teams caring for the system as a whole, rather than just individuals caring for their own small part.

I don't think this rule is too much to ask. You don't have to make every module perfect before you check it in. You simply have to make it a little bit better than when you checked it out. Of course, this means that any code you add to a module must be clean. It also means that you clean up at least one other thing before you check the module back in. You might simply improve the name of one variable, or split one long function into two smaller functions. You might break a circular dependency, or add an interface to decouple policy from detail.

I really like this idea a lot. I've heard Wil Shipley articulate it as "clean as you go" - if you see something messy, fix it then and there.

You should definitely check out 97 Things Every Programmer Should Know. I bought it as a DRM-free ePub from O'Reilly (with the buy-one-get-one-free coupon code "BYGET" - don't know how long that's valid for). It reads just perfectly in Stanza on the iPhone.