Human salvation lies in the hands of the creatively maladjusted. —Martin Luther King, Jr.
Step One on the Eight-Fold Path to Technological Enlightenment is to gain the Right Understanding. Analysts seek understanding, so Chapter 1 covers analysis, creativity, and especially thinking like an analyst. It talks about tools, but mostly tries to loosen your mind to get you outside that proverbial box everyone has been thinking inside of. It even shows you where the box is.
Nirvana, or in Japanese satori, is the state of sublime understanding. It’s not a place, but a mode of thought—Daisetz Suzuki tells us of satori that “The object of Zen discipline consists in acquiring a new viewpoint for looking into the essence of things”—as concise an explanation of thinking like an analyst as I’ve ever read. So in this section you’ll learn to think like a Systems Analyst in order to reach the nirvana of systems understanding. You need to get into a certain mode of thought to be a good analyst, and sometimes need to look at the world a little differently.
The first step is often the hardest step in solving any problem. When my programming students get stuck on an assignment, I usually tell them “You might not know how to solve the problem, but you do know how to do something needed for the solution.” In other words, if you don’t know how to do it, don’t you know how to do part of it? You don’t know how to do the calculation, but you know you’ll have to input data. Start with that. The Japanese have a proverb: Sen ri no michi mo ippo kara: “Even a journey of a thousand miles starts from one step”, and it's absolutely true when undertaking analysis or moving to on to any new phase in the SDLC (System Development Life Cycle—see Chapter 7).
Sen Ri no Michi mo Ippo kara
“Even a Journey of a Thousand Miles
starts from One Step”
The strategy is to divide and conquer. Break the problem into bite size pieces. Anne Lamott has written a delightful book on writing called Bird by Bird: Some Instructions on Writing and Life. The title came from a childhood incident when her young brother needed to write an essay about ornithology, and felt overwhelmed by the work ahead. The advice the author’s father gave to him: “Just take it bird by bird.” So, if you need to get started, but feel overwhelmed, just take it step by step, interview by interview, module by module, bird by bird.
Yin and Yang, called Inyō in Japanese, is denoted by the symbol called Taikyoku in Japanese, T’ai Chi in Chinese. Taikyoku is also the name of a kata in Karate (the subject of the book I wrote with Ferol Arce, The Taikyoku Kata in Five Rings), and a slow-moving Chinese martial art. The symbol’s on the cover of this book, and looks like this:
[
Yin and Yang are represented by the dark and light areas in the circle. Notice there is a little piece of light in the dark, and vice versa. This is because there is always a little bit of Yin in every Yang: there is light within dark, strong within the weak, good in evil, and vice versa. These Yin/Yang pairs are sometimes called opposites, but that is not accurate—they are actually complementary. One could not exist without the other. A young martial artist then living in Oakland, California, explained this in his 1963 book: “The ‘one-ness’ of Yin/Yang is necessary in life. If a person riding a bike wishes to go somewhere, he cannot pump on both pedals at the same time or not pump on them at all. In order to move forward, he has to pump one pedal and release the other. So the movement of going forward requires this ‘oneness’ of pumping and releasing.” Incidentally, this particular martial artist later left Oakland to pursue a career in entertainment, of all things. I heard he even made a couple of movies. His name was Bruce Lee.
Sensei Ferol Arce of Wado Ki Kai Karate Dojo tells us a punch is made more effective by the retreating hand, so both the so-called yin and yang hands are critical to the technique. In fact, the retreating hand should be thought of as an attack—an elbow strike to the rear. Likewise, your system will need to blend business with technology, people with machines, and analysis with design if it is to succeed. Some systems analysts argue: “Analysis does not include design. You must never let design enter your mind during analysis.” I’ve always found this profoundly silly. Imagine someone telling you he has just completed a thorough analysis of a vehicle:
“What kind of vehicle?” you ask him.
“I don’t know, that’s a design issue and I analyzed the vehicle”, he replies.
So you ask: “Well, how will it be used?”
“I have no idea, that’s a design question and I was doing analysis”, he replies.
You probe further: “Does it roll, or fly, or float?”
“Beats me, that’s about design and I did an analysis”, he replies.
Etc., etc., etc.
This obviously makes no sense: you can’t analyze something if you don’t even know what it’s used for. Likewise with your analysis, there will always be some analysis in your design, and design in your analysis (Yin and Yang).
Tasks that are hard to accomplish can be grouped into two categories: unpleasant work, and difficult work. Embrace contradiction: Opposite approaches are needed for these two categories. For the unpleasant, the Nike motto is best: “Just do it”. It’s not going to get any better, so get it over with; the time you’ll spend dreading it will increase the total unpleasantness, so unless you can avoid it permanently (probably the best approach of all), get it over with.
For the difficult, the approach is reversed. Use the Power of Positive Procrastination. Sleep on it. Let it sit in your subconscious for a while. Do some thinking about it from time to time, but delay the decision as long as possible. If no answer is required for several weeks, start a folder on the problem, then put it aside. Pick up the folder every few days and think about it a little, but don’t force it. A certain Zen acolyte was given an especially tricky koan, a difficult riddle as an exercise to help him gain understanding. When he asked how long it would take to master the koan, he was told, “About two years”. “But what if I study really, really hard?” “Then it will take you about twenty years!” was the reply.
Over time,
Unpleasant tasks become more unpleasant,
but
Difficult tasks become less difficult.
One technique for managing difficult questions in meetings and facilitated sessions is the parking lot. It allows you to defer difficult questions in the hope they will resolve themselves. In this technique, you take a sheet of paper or board and label it “Parking Lot”. When something comes up you can’t resolve, simply note it on a Post-It note and place it on the parking lot. Since it’s visible, and will be taken care of, you can safely ignore it for the time being. At the end of the meeting, or each day for a multi-day meeting, review the parking lot. You’ll be surprised how many of the items will take care of themselves. Those that haven’t by the end of the session are assigned to someone, and recorded on a task list for follow-up. The parking lot can also park unnecessary detail. In a CRC Card Session, I use the back of the card for a similar purpose. Someone will have been sent to the session with strict instructions: “Make sure you tell them about the new manufacturing classification we need.” So at every turn, this poor guy tries to bring up this low-level detail. No problem, just write it on the back of the CRC card. He now sees it’s been recorded and will shut up about it, and you have recorded it so won’t forget it.
Now the tough part. What if a problem is both unpleasant and difficult? I’ll leave that as a koan for the reader.
I was once browsing through a book on Systems Analysis looking for examples of problem statements when I found an example of an analyst whose boss sent him to look into a problem in Accounts Receivable. The Analyst spoke to the Receivables Manager, who indicated she needed a report of those customers who were past due on their accounts for whom there was no telephone number on the database. I turned the page expectantly, hoping to see how the analyst rooted out the cause of the problem. To my disgust, there was a problem statement: “Need a report that shows past due customers with no telephone number.”
I almost threw the book across the room, because a need for a report, or screen, or even a system, is never an analysis problem. It may help to solve a problem, but it is not a problem in itself. Of course, a report (screen/system) could be giving incorrect information, thus making it a programming problem, or be poorly designed, thus making it a design problem, but the need for a bug fix is not an analysis problem. In the example given, the problem was “We don’t have the telephone numbers for customers we need to contact because they haven’t paid their bills.” The analytical question is “Why don’t we have these telephone numbers? Why did we lend money to people we can’t contact?” Is an edit needed on the input screen to require a phone number? Are they unable to capture contact information at the logical time? Maybe it’s not on the form, or in the database. Or is it captured, but later lost?
And I’m sure you’ve seen this example, maybe not exactly this way, but something similar. Say a sinkhole develops in the street near your home. You call the local government office in charge of roads and get a refreshingly interested response. “This is terrible, cars could be damaged, people could be hurt. Something must be done, something will be done!” Sure enough, right away a crew shows up, and installs prominent signs: DANGER: Rough Road.
[ [ [
Look for what a Quality guru calls the root cause. You need to understand WHY the problem started, so ask why’s until you’re wise. Now your next question is probably: How many why’s do you ask? Most children figure out the why word can always be grammatically and logically used to reply to any statement. “Time for bed.” Why? “Because you have to get up early.” Why? “Because you have to go to school.” Why? “So you can get a good job.” Why? Etc., etc., etc. The only escape is the famous Because-I’ll-give-you-a-spanking-if-you-ask-why-again tactic. So I’m afraid this is one of those Zen situations, you’ll know the answer when you hear it. In Kaizen and Gemba Kaizen, Masaaki Imai suggests you ask why five times, even calling the technique “Five Why’s”, since chances are five will uncover the root cause.
In one example, a worker is throwing sawdust on the floor. Why? Because the floor is slippery. Why? Because there is oil on it. Why? Because the machine is dripping. Why? Because there’s a leak in the oil coupling. Why? Because the rubber lining is worn, and needs replacing.
In an example given by a Toyota Vice President, a machine stopped running. Why? Because an overload blew the fuse. Why? Because the bearing wasn’t lubricated properly. Why? Because the pump wasn’t working right. Why? Because the axle was worn out. Why? Because sludge got in it.
I’ve experienced this example: the report is wrong. Why? Because wrong data were entered. Why? Because the user mistyped the data. Why? Because the user was confused. Why? Because the programmer didn’t understand the problem. Why? Because of incomplete analysis. Always ask yourself: “Is this a problem, or a solution, or a solution looking for a problem?” Are you attacking the problem, or just a symptom? Don’t fight the fever, fight the disease causing the fever.
To get to the root cause,
Ask “Why” five times.
The Rule of Five is more or less arbitrary, but the ancient Greeks sought the quintessence, that is the fifth essence, of all things, so they seemed to agree the real answer is five levels from the apparent. When should you stop asking why? When you’ve gone too far. Sometimes it’s only clear you have the root cause when you’ve gone beyond it into the realm of the child’s recursive why.
In many systems analysis courses, the section on modeling the current system is followed by a segment on recording the new, dramatically improved system, with lunch in between. How the brilliant new design appeared from the current design never explained, so during lunch, a miracle must have occurred to make the new solution appear. And of course the new solution was the creative part, the part you most need help with.
Many books and gurus will tell you the best way to solve a problem is to “Be Creative!” Now, why didn’t you think of that? Perhaps you weren’t creative enough to think of it. The difficulty is that you can’t just write in your calendar: “Tuesday morning, 9:00-11:30: Be Creative”. If you press, this advice will be made a bit more specific: “Think outside the box!” Just what box are we talking about?
The familiar connect-the-nine-dots exercise. The problem is: “Connect the nine dots by drawing a series of straight lines without lifting your pen.” The twist to the problem is this: The obvious solutions require using five or more lines. Your task is to do it with fewer than five lines. Try a few:
• • • • • • • • •
• • • • • • • • •
• • • • • • • • •
HINT: A number of solutions are not obvious because of a requirement that we mentally read into the problem. Most people construct an imaginary box around the nine-dot pattern. Some people even describe the pattern as “Nine dots arranged into a box”. So, you guessed it, the solution to this problem will require you to think outside the box. The usual solution offered is a four-line solution that involves arranging the lines such that we get an outside angle on the dots, extending the line outside the mental box we constructed around the dots. This is the famous (or infamous) box everyone is trying to get out of.
But there are actually several one-line solutions available to Zen analysts, and they don’t even require you to go outside the box. You could use a calligraphy brush to draw a line such that a single line passes through all the dots. Another is to use origami (the Japanese art of paper folding) and fold the paper so the three rows of dots align with three dots touching at the edge. Then use a pencil to draw one line through the dots.
The point of all this is to “Think Different”, and get the creative juices flowing. Some people find this exercise either entertaining or silly. But it makes a great icebreaker, and helps loosen people up, and that can allow creative thoughts to flow.
[ [ [
Try to discover your most creative time of day. I tend to get my best ideas in the early morning hours after I’ve just awakened. I usually think best if I don’t turn the lights on, a problem since I can’t see to write the ideas down. Since I’ve reached the point that I know so much that to remember anything new I need to forget something to make room for it, I keep a pad in my pocket in the day and by the bed at night, so I can scrawl down my fabulous ideas that I later can’t read. I’m also working on a way to take notes in the shower but I can’t reveal anything until I get the patent. But seriously, just the act of preparing to take notes can put you in the right frame of mind.
Creative people usually keep on rolling with the flow. Mick Jagger of the Rolling Stones says he never tries to compose lyrics in verse. Even though his lines must rhyme, he says rhyming as you write slows the flow and ruins it. The same is true with writing—don’t try to write grammatical sentences with kurektly spellt wurds. Just let the words flow, then go back, correct any errors, and make it sing. Likewise with starting a system or writing a program—start with a small step and go from there.
[ [ [
And don’t forget: if you take another person’s idea, it’s plagiarism, and despicable. But if you take two or more people’s ideas, it’s research, an admirable pursuit worthy of the true scholar you are. So steal ideas shamelessly, from books, friends, movies, plays, even the world itself.
When I was a junior economist before I got into computers, I was sent to a class on computer principles for non-technical people (“users”) like myself. A tape was played of a speech that had been made by one of a pair of young men who had started a consulting firm using the power of computers in new and exciting ways. Unfortunately I’ve lost the reference but it’s a good story that illustrates some important points even if I might not have the details right. As Ken Kesey would say, it’s a true story even if it didn’t happen.
They were just out of school, one with a degree in Mathematics and one in Computer Science. There is a technique in mathematics called “linear programming” that was developed in the early nineteenth century. Despite its name, it has nothing to do with computer programming, but as its name might suggest, it was ideally suited to the computer. In fact, linear programming had been considered something of an oddity. Although it was a method of solving problems involving simultaneous linear equations, and there were many applications where solving these equations would be valuable, it was so tedious and time consuming as to be impractical. And then along came the computer, which excelled at tedious and time-consuming work.
Our heroes decided to specialize in linear programming. They arranged for some computer time, worked up some programming programs (that is, computer programs to do linear programming) and found a likely application. They had studied at U.C. Davis, and so being good Aggies they not surprisingly came up with an agricultural problem. Are you ready for this? It was chicken feed. No kidding, chicken feed.
Now chicken feed might not sound too complicated to you, but in fact it is. There are literally hundreds of different commodities that can be used to make chicken feed: corn, wheat, rice, sorghum, etc. Each has a certain amount of calories, vitamins and minerals. The trick is to mix the ingredients such that the resulting feed has the right amount of each of the dozens of vitamins and minerals needed to make a happy and healthy, not to mention profitable, chicken. This problem might sound like it would have been solved years ago, but there is an independent variable, as mathematicians are wont to say: each of the hundreds of commodities that can be used has a price, and that price is constantly changing. So the ideal chicken feed formula literally changes every time some commodity is sold on the Chicago Board of Trade. As the price of a commodity goes up, you should use less of it. But this lowers the amount of each vitamin and mineral that commodity contains; and so you’ll need to increase other commodities to make up the deficits. Surprisingly, it will be rare to simply lower the amount of one commodity and replace it with another, because the mix of nutrients is different in each. To put enough of the new commodity in to replace the nutrients that the old commodity is high in you’ll inevitably wind up with an excess of whatever the new commodity is high in. Reducing this surfeit will almost always entail adjusting the level of a third, and a fourth and then a fifth commodity. I probably haven’t done a very good job of explaining the complexity, but trust me, I took a course in Mathematical Economics in which we devoted much of the semester to these types of problems and they are a lot harder than they look.
So our heroes found a client to experiment with. The feed company would let them work up chicken feed formulas on approval, which is to say, if the company didn’t approve of the results, they wouldn’t get paid. The company’s formulas were the work of a couple of wizened old men who had done this all their lives. They looked over the commodity prices each day over coffee. Most days they’d keep drinking and coffee reading the newspaper, but some days they’d see something that caused them to spring into furious action. If the prices called for it, they’d spend frantic hours making up a new formula. That’s a chicken feed formula, not a mathematical formula, because they used no math of any kind in their decisions. It was all gut feel. Our heroes wondered why they didn’t just consult the chicken entrails, since that would have been about as scientific as the method they were using. The company’s problem was the formula guys were both approaching retirement age, and no successors were evident.
So, our heroes got all the USDA figures on nutrition content, and the numbers for the ideal meal for super-chicken, and set up their computer to determine the ultimate chicken feed. Some hours later (even with the best computers of the age, the calculation took a long time) the answer came back, and exceeded even their wildest expectations: they had a formula that would produce feed for less than a quarter of the current cost. Triumphantly, they returned to the company with their recipe.
“That will never work!” said the formula makers.
“Why not?” asked our heroes.
“Too much molasses”. It seems molasses is runny, and if you put more than one or two percent in the mixture, it just runs out of the burlap bags.
“Why didn’t you tell us about molasses?” our heroes asked.
“Everybody knows,” they replied, “that molasses is messy”.
[ [ [
But this was not a real setback. They simply gave their computer one more constraint, et voila, a few hours later, another fantastic recipe. This one saved a little less than half, but that’s still pretty darn good! So, they rushed back to the company.
“That will never work!” said the formula makers.
“Why not?” asked our heroes.
“Chickens won’t eat that.”
“Why not?”
“The mixture will be reddish-brown in color. Chickens won’t eat anything red or brown.”
“What, do chickens have color fetishes?”
“No, but it will look like dirt to the chickens.”
“Why didn’t you tell us about colors?” our heroes asked.
“Everybody knows,” they replied, "that chickens don’t eat dirt.”
[ [ [
Now this was a little more complicated, but not impossible. It took a couple of weeks, but they were able to build in the color components of each ingredient and make sure the result would appeal to even the most discriminating bird’s eye. The resultant formula only saved fifteen percent or so, but that can add up to a sizable sum over the years.
“That will never work!” said the formula makers.
“Why not?” asked our heroes.
“The formula is too rich. It will cause diarrhea.”
“Why didn’t you tell us about richness?” our heroes asked.
“Everybody knows," they replied, “you don’t want your chickens to have the runs”.
[ [ [
And on and on. They kept reformulating, with each attempt losing more and more of the cost advantage, until they finally ran out of money and had to give up. At that stage, their best formula was within one-half of one percent of the cost of the formula the old guys had concocted using their unscientific approach. The company started a crash course to train some new feed formulators.
Beware of What Everybody (except you) Knows
When you are involved in a development project of some kind, be it for a new computer system or a new way of doing a manual process, beware of what everybody (except you) knows. There is often an assumed level of knowledge. They’re not being malicious (that’s another problem), it just never occurs to them you wouldn’t know. The analyst’s job is to uncover the system—the users job was to make chicken feed, and they were quite good at it.
This is true both when you are trying to understand something, and when you are explaining something to someone who is unfamiliar with it. There are a lot of unspoken assumptions shared by those familiar with a process that will not be obvious to those who are not familiar with it. And remember, the human mind has an amazing tolerance for complexity and ambiguity that computers do not.
One upon a time the fishing was excellent on a certain riverbank. Many people came to fish there, and, in time, piers were built to fish from. One day, a ferryboat company was formed to take people across the river, and quite naturally decided to dock at the existing fishing piers. Over time, the piers were enlarged, roads were built to the ferry landing, facilities were built, and the area was generally improved. As time passed, and more and more people crossed, it was decided to build a bridge. Because there were roads and land available at the ferry crossing, it was quite natural that the crossing point chosen for the bridge was the ferry landing. Soon the bridge was ready, and signs were posted: “No fishing from Bridge”, which is quite ironical, since the bridge would not have been there if it had not been such a good place to fish. Not only has a great place to fish been lost, but the bridge is not in the ideal location for a crossing, either. The legacy system (fishing) caused the eventual system (the bridge) to be in the location it was, which was actually ideal for fishing, not crossing. If you don’t think this fable applies to computer systems, consider how many programs today are optimized for punched cards. As I pointed out in my first book Solving the Year 2000 Crisis, the Y2K problem is an example of a “Good idea at the Time” leading to serious problems down the road. Take care when determining why things are as they are. It could be for a good reason, a bad reason, or no reason at all.
Things are the way they are
For a good reason,
For a bad reason, or
For no reason at all
There is a tendency to think things ought to be as they are. David Hume pointed this out as a fallacy of assuming whatever is ought to be. In history, we often assume the actual victors ought to have won: “Luckily, Hannibal was defeated, and Rome was saved.” But if things had gone differently at Zama, we’d likely say, “Luckily, Scipio was defeated, and Carthage was saved.” If you assume what “is” ought to be, there will never be improvement. In Hume’s time, there were colonies, slaves, peonage, diseases, etc.
Hume’s Fallacy:
No ought deducible from is
Let’s consider some cases where there was a good reason to do something a certain way, but now that original reason is no longer valid.
If you leave a floppy in your PC the machine won’t boot up, because the original PC had to boot from the floppy since it was the only drive the machine had. But now when every computer boots from the hard drive we’re still stuck with that annoying protocol. An argument is made it needs to continue that way so that in the event of a hard disk crash you can still start the machine. Maybe, but couldn’t the procedure look at the floppy, and if it doesn’t find a system disk, go to the hard drive? And nowadays, if your hard disk crashes you’ll get it fixed, not revert to the old floppy method.
The familiar QWERTY typewriter keyboard was designed to avoid the problem of the hammerlock. In a manual typewriter, a mechanical linkage connected the key to a hammer that struck an inked ribbon to imprint the letter on the paper. When a typist is typing very fast, one hammer can come up before the other is back down, and they clash, causing an annoying jam. The closer the two hammers are in the carriage the more their arcs overlap and so the more frequently they jam. The QWERTY layout was designed to separate keys that were often adjacent in English words, and so avoid this problem. The original reason is gone with the hammer, but we still have QWERTY, and probably the commands typed in on the spaceship arriving at a distant galaxy in the next millennium will use QWERTY.
Many Management Information Systems produce reams of reports that no one looks at. They track items that are no longer important, or that can be tracked better or easier through another method. When in doubt, turn them off—maybe no one will ask what happened to them.
But perhaps the most troublesome example of a straitjacket constraining progress is the legacy curse.
Legacies are usually good, being something inherited from your rich ancestors. The legacy curse is the problems caused to a cutting-edge high-tech IS Department because its core systems are running on technology from decades ago. Usually written in Cobol, or even C, the problem with legacy systems is they are too good to throw away but not good enough to take you to a new level. The World would a better place today if Y2K had caused every computer and computer program on Earth to melt down and be completely unusable. Within a year or two, we’d have replaced all the old junk with something new and be rid of the Legacy Curse.
Legacy systems are victims of their own success. Your company has come to depend on its legacy systems, but cannot afford to replace them. For one thing, a replacement would be developed over months, but would require a similar investment to that made in the legacy system over a period of decades. But most important, the system has become critical, and so you must keep the old system running while replacing it. If you have ever had to live in your house while re-building it, you’ll have some sympathy for the problem. Similarly, refitting the Oakland-San Francisco Bay Bridge would probably cost more than it would cost to build a new bridge from scratch, because we need to use it while we’re working on it. In some cases, replacing a legacy system is like replacing an airplane’s wings in flight.
Sometimes, the only reasonable choice is to build around the legacy. You surround, or “wrap” the old system in new technology. The design of the human brain is a wrapped legacy system: It includes a dinosaur brain. There’s the reptilian portion, the legacy system, with a mammalian portion built on top of it. Redundant, and often at cross-purposes, it fails to maximize the use of the new technology—a poor design. However, the species had to stay alive while the better brain evolved, so we have both. The new technology, in fact, “surrounds” the old.
The evolution from four-legged to two-legged animals led to a poorly designed back. At every point it had to be better than the design before it; you can’t say “Look, Mother Nature, to get you the best possible two-legged creature, we’re going to have to suffer a minor setback for one or two million years, but in the long run you’ll have a much better back to work with....”. A two-legged creature has his hands free—but four-legged creatures don’t have hands: to have two feet free would be of little value. The feet had to simultaneously evolve into hands: fingers and an opposable thumb. Likewise, standing up to see is of little value until sight improves. And you can’t stand on two legs without a balance system (inner ear). Bringing all these pieces together took time.
And similarly, the current system might put severe limitations on any new system. The users may insist each increment is an improvement, and all features be available at the same time. But, you can usually still improve dramatically: You don’t get the best possible solution, but you can usually get a workable solution. The design is better every step along the way, although you might wind up with a dinosaur brain in the center.
Okay, you’ve been working hard on this stuff, so now I’m going to tell you to take a break and watch TV. Interviewing skills are indispensable during systems analysis. You must be able to extract sensitive information without offending. If you’d like to see a master at it, watch Booknotes on CSPAN sometime. It’s no longer produced, but the 800-odd episodes are available on the Booknotes website, www.booknotes.org. The host, Brian Lamb, spends an hour discussing a book on politics, history or current affairs with the author. The program is always interesting, not just for the topic of the book, and because he also discusses the process of writing, which has similarities to systems development, but especially because of Brian’s interviewing style.
His style enables him to ask sensitive questions without offending the interviewee; in fact, he draws the author out, asking questions that might have evoked anger if asked by anyone else. He is able to ask questions that normally would draw a “None of your Business” and get the author to answer without the slightest hesitation or offense. “How much money did you make on it?” or “What made you think you could write a book on this topic?” He also usually asks about the book dedication, especially if the author has concealed the identity of the dedicatee.
If you can’t catch the show, many show transcripts have been collected into the book Booknotes: America’s Finest Authors on Reading, Writing, and the Power of Ideas.
Copyright ©2003, 2008 Patrick McDermott