I'm trying to make sense of the "Voice of the Customer" as the 6σ folks term it.
I get email once in a while on my books (Programming , Python and OO Design ). The volume of mail indicates that I have a few hundred readers. I'm honored to have readers who respond with intelligent comments, suggestions, corrections and questions.
Recently, I was asked to include a section in the "Programming for non-Programmers" book on some fundamentals of computer science -- things like the essential fetch-execute cycle. I balked, thinking this is too deep. My original idea was a "gentle", or "lay-person's" introduction to programming. Too much depth can be intimidating.
This happens in SCUBA diving: if you can see the bottoms and edges, 30 feet doesn't seem deep. However, when you're in really deep water, 30 feet is paralyzingly fear-inducing. SCUBA training moves from confined water to open water just to separate essential skills from the scary context.
Deep Water
My original intent was to have the first book be more like SCUBA pool sessions. Nothing too serious, just technical facts about the Python language -- enough to get someone up and moving around, making some progress.
However, what I'm hearing is that some of the theoretical foundation is a helpful thing, perhaps even necessary. I think we can avoid getting into deep water by putting this stuff in an "advanced topics" side-bar.
This is one of this topics that I take for granted. It seems so obvious that one hates to belabor it. Indeed the multi-layered fetch-execute cycle of an interpreted language like Python can be an elegant bit theory that does help someone who's confused by "how it all works."
Don't Go There
On the other hand, I've had folks explicitly reject my attempt to get some deeper information. Specifically, I was recently told that exploring the use cases for a badly-performing piece of SQL was senseless. They told me in no uncertain terms that the SQL lived in a shallow, purely technical world, and understanding how the data got into the database, who needed to see it (and when) didn't enter into the question they were asking.
In this case, the voice of the customer was to avoid depth.
However, these two cases don't directly compare. The plea for shallowness was from a reader who has repeatedly asked for Faerie Dust ™ solutions (also, Faerie Dust™, Part II ). Their most recent query was similar to the original Faerie Dust posting -- they had a piece of SQL that was slow. Generally slow SQL is a result of a poor data model (if you've written your code even reasonably competently, the data structure and algorithm are complements). However, every kind of change was off the table except SQL changes. There could be no data structure changes, no process changes, nothing but some magical SQL thing which would make a bad structure fast.
Balancing
There isn't really too much challenge in balancing these. One customer has sensible questions about fundamentals. Another has some kind of fear of fundamentals.
For the book, I had a vision of someone being able to learn in a very controlled environment, and grow into an appreciation of the fundamentals. My customers, however, are telling me that I should not defer mention of the fundamentals. I need to stop worrying that depth can be intimidating. Instead, I should point out that there is some depth, and given an outline of how much depth there really is.
In some cases, people don't want the depth; they can skip over the presentation. However, if the depth isn't there, there's nothing for the people who want to build their skills in a different order.
On-Line Updates
Since my books are online, I don't have a complex "2nd edition" publishing cycle. I can make the changes as soon as I can get to them. I think this is -- possibly -- one way in which my books might have some enduring value in the marketplace. I'm willing to change an adapt to the voice of the customer.