Naming the Red Couch

Shel and Robert, at The Red Couch are looking for a title for the book they’re writing on business blogging. Their working title up to this point, “Blog or Die!”, has come under scrutiny for various reasons, not the least of which is that in some parts of the world the choice to blog is truly life or death.

After throwing some ideas around, Johnnie Moore and John Moore both suggested “The Red Couch” as the main title. As John commented:

Don’t get roped into a generic and homogenized title. After all, a good blog is not generic, nor is it homogenized — your book title shouldn’t be either. (Dig?)

THE RED COUCH title is different enough, intriguing enough, and compelling enough to one’s capture attention. Keep in mind … at some point soon the term ‘blog’ will become fatigued. (Double dig?)

“THE RED COUCH: Why Conversational Marketing and Blogging is Essential to Business”

Jim Minatel, the editor, would rather play it safe with a more literal title, such as “Just Blog It!”, “The Human Corporation: How Blogs Improve Everything In Your Business”, and “Let Your People Blog: Why Conversational Marketing is essential to Business”, for some classic reasons:

I’m the one who so far doesn’t buy the “Purple Cow” style titles for this book, even though I love it for Seth’s book… What works for previously established authors like Seth Godin and Malcolm Gladwell might not be the best recipe for first time authors.

And what works for the blog-enlightened crowd that’s reading the Red Couch blog today, might not be the best title to sell to a broader audience that hasn’t yet bought into the value of blogs 8 months from now. We hope everyone here is going to end up liking the book enough to buy or recommend it regardless of the title. But none of you need to be sold on blogging, you are already the leading 1% (or a fraction of 1%) of the bigger business audience. If Shel and Robert are going to help spread the blog vision to business people who haven’t got it yet, the first step in that has to be either them picking the book up on their own from the business section, which I don’t think “The Red Couch” will get them to do, or from your recommendation.

There are two assumptions in Jim’s reasoning that I feel need to be challenged. The first is the assumption that Robert and Shel are first-time authors. It may be true that neither has ever published a book before, but they have already built a large and influential readership. Regardless of the title of this book, it is going to sell well; which brings me to the second idea assumption I’d like to challenge: that the Clueless Joe in the bookstore is the market that matters.

The way people find books has changed dramatically with the rise of the internet. It has for me, anyway. Nearly all of the books I buy these days are recommended to me somehow: by a friend, Amazon reviews, bloggers, or comments on various forums. In the past five years, I can think of one book that I’ve purchased at a bookstore base solely on the cover material. My usual approach when I find a book that seems promising at a bookstore is to make a mental note of it, put it back on the shelf, and check the Amazon reviews when I get home. I don’t trust cover material any more than I trust used car salesmen. I could be an anomoly, but I don’t think I’m alone. What sells me on a book is independent reviews; word of mouth, as they call it.

The uninformed guy in the bookstore is irrelevant. Some of the most influential people in the world are already raving about The Red Couch. Somehow their recommendations are going to reach him and he will buy it, regardless of how silly the title may sound.

So my advice for Jim: Do something remarkable. You don’t have anything to lose.

SICP, Dijkstra, and Plato! Oh my!

As somebody reading and working through the exercises in SICP, I enjoyed the paper Jim Brown posted about it entitled What’s in the box?: Abstraction and Regimes of Truth in Computer Programming. While the focus of the article is on what it means to treat procedures a black boxes, the part I found most interesting is where he likens the differences between the bottom-up approach of SICP and the top-down approach of Dijkstra to the differences between Aristotle’s and Plato’s epistemologies:

For Plato, we must understand truth prior to entering into dispute or argument, otherwise we will find ourselves lured by faulty “resemblances”. This is Dijkstra’s point when he warns of the dangers of testing programs before they are properly finished. One should know their program perfectly before testing it. Trial and error was a flawed technique for these programmers. Abelson and Sussman, on the other hand, are more interested in the negotiation and collaboration that happens in the programming community. In this sense, their method seems more akin to Aristotle’s description of rhetoric. In Book I of the Rhetoric, he differs from Plato’s view of rhetoric as mere persuasion: “[Rhetoric’s] function is not simply to succeed in persuading, but rather to discover the means of coming as near such success as the circumstances of each particular case allow (1328). Rhetoric is then useful because it gets us as close to truth as possible, and this should remind us of Abelson and Sussman’s assertion that, “we become convinced of program truth through argument.”

Solution to SICP Exercise 1.14

Structure and Interpretation of Computer Programs

Solution to Exercise 1.14:

The process generated by the count-change procedure
Click to enlarge.

The count-change is Θ(n) in space. Like the fib procedure, the space required is equal to the maximum depth of the tree, which occurs on the combination that is all pennies.

I believe, though I could very well be wrong, that the process is Θ(n2) in time as the calls to cc tend to double with increments to n.

I couldn’t get conclusive timing numbers out of DrScheme to confirm this belief. Here’s the code I was using to test

(require (lib "" "srfi"))
(map (lambda (amount)
(let ((start-time (current-time time-process))
(change (count-change amount))
(end-time (current-time time-process)))
(let ((diff (time-difference end-time start-time)))
(list (time-second diff) (time-nanosecond diff)))))
(list 100 200 300 400))

The output was ((0 160000) (0 2810000) (0 1560000) (1 6560000)). I don’t understand why the third time was consistently less than the second. Anybody care to enlighten me?

More on Web Apps

Michael has my comment to his comments on my earlier post about Evan Williams’ post on web applications (Good god! Let’s just say we’re having a conversation).

He considers the fact that web app hosters have root access to your data a point against web applications, as a hosting insider could do any number of undesirable things with the data.

It could be argued that the same applies to internal IT staff. Your IT guy could be selling company email addresses to spammers on the side, for example. I agree, though, that when a hosting company does it, they are probably better organized and can do more damage.

Michael also points out the dearth of APIs for web applications, which I agree is regrettable. On the other hand, there’s no technical reason that a web application can’t have a decent API for manipulating its data. We’ve come to expect API’s for local applications, why not for web-based ones?