What Good Bosses Should Believe

Posted on June 1, 2010 by Krishna

Bob Sutton is hard at work on a new book and has put together a set of key beliefs that good bosses have. My thoughts on some of them:

1) I have a flawed and incomplete understanding of what it feels like to work for me.

12) Because I wield power over others, I am at great risk of acting like an insensitive jerk — and not realizing it.

Despite however good you think the relationship between you and your team is, it is always corrupted to an extent by the power that you have over them. When you are “persuading” someone, part of the influence comes from that power. Your “two cents” input is worth a lot more when compared to that of your team members. This is a problem in the best of circumstances. It becomes even worse when you are operating in a crisis and have to exert that power explicitly.

The key part of Bob’s insight is that as a manager, it is impossible to understand how much of a problem this is. It helps if you have worked under a bad boss and have (unfortunately) experienced things that have ticked you off the wrong way. But ultimately, people are different and what you may think is not a big deal may matter a lot to someone else. So there are real limitations to the reality of what you think will be received well by employees. For example, take a look at Steve Rowe’s experiences with his team.

Bob also talks about how being a good manager is all about balancing different priorities and different kinds of behavior.

4) One of the most important, and most difficult, parts of my job is to strike the delicate balance between being too assertive and not assertive enough.

6) I strive to be confident enough to convince people that I am in charge, but humble enough to realize that I am often going to be wrong.

To relate to the previous topic, let’s say that you always try to elicit opinions from your team before making a decision. But in a particular instance, you sincerely believe (based on your experience) that the team consensus is wrong and will produce poor results. Faced with the need to exert your authority to override the team’s idea, how do you avoid being seen as authoritative or, worse, arbitrary? How do you ensure that your employees will not take the rejection personally and refuse to provide valuable suggestions the next time you need input?

In such situations, poor managers take the path of least resistance. If they are more interested in doing “what needs to be done“, they will do it riding roughshod over everyone’s feelings, creating a disaster for future team cooperation. Or, conversely, if they want to be popular, they will go along with everyone or procrastinate in making tough decisions, thus creating huge risks for the organization. Considering both sides is difficult, but essential to good management.

Also, about how bad managers are always thinking about new initiatives to “motivate” employees instead of fixing things that are broken:

10) Bad is stronger than good. It is more important to eliminate the negative than to accentuate the positive.

One of the stupidest books I read was “Fish” (sorry, no Amazon link to trash!) which asked managers to make work “playful” through various “fun”, “team-building” activities so that they could improve employee morale. The idea apparently is that employees will forget 40 (or more) hours of mind-numbing work if you just let them play a bit.

Good managers understand that you have to work on making the work and workplace worthwhile. If the workplace is mired in bureaucracy, the work makes no difference, the infrastructure is crumbling, then all the silly activities you can think of will not build a good team. You need to get rid of the stench first, then bring in the espresso maker.

Read the whole thing.

Posted in project management | Tagged , | 1 Comment

The Quality Imperative

Posted on May 10, 2010 by Krishna

Alan Skorks has an interesting post on different ways to look at software development: (emphasis in the original)

the majority of companies that build any kind of software are ‘software as a destination’ companies. [...] On the other hand, most individuals who build software for those companies would instinctively like to be (and in many cases ARE) ‘software as a journey’ people. [...] there is a fundamental disconnect between what a company wants to get out of building software and what the developers will try to extract from the experience. [...]

There was a bunch of people ["the agile movement"] [...] [who] decided to give a united voice to the message that as long as you take care and extract the maximum benefit along the way, the destination will take care of itself – you will arrive somewhere you want to be. It may not be exactly the same place where you thought you would end up, but it will be a nice place nevertheless and best of all, you will have a very good idea of precisely how you got where you are, despite not having a narrow focus on the final objective from the start. [...]

But, it is so much easier to simply look towards the goals and on paper it seems like it SHOULD be more efficient. If you’re in management you want to seem more efficient and focused rather than being wishy-washy and touchy-feely, preaching self-awareness and a less-rapid pace just isn’t strategic enough. And so companies create artificial deadline pressures (like end of financial cycle of some sort), to make everything neater and make the people in charge look good and it feels like for every step the agile movement takes towards running software projects better, some company somewhere, takes two steps back.

This is right to some extent, but it also misreads the situation especially with respect to the Agile movement. What Alan writes is not only true for software companies, it is true for every company in the world. All organizations have goals and there is always a tendency towards meeting those goals as quickly as possible using as few resources as possible. This is true for car companies, schools, non-profits, financial firms, and so on. But in all these companies, you can also find people who want to bring the focus back on the process by which these goals are achieved.

And so there is a tension between these two sides (goals versus processes). But they are not mutually exclusive as different quality movements n the last century have shown us. Better processes ensure that goals, once achieved, can be sustained and that greater use of resources to maintain quality pays back in the long run. This is not a discovery of the Agile movement. Every quality initiative you can think of, including Six Sigma, CMMi, etc. are all attempts to bring the focus back on process.

The practical difficulty has been understanding how much you want to invest in quality (“time/money“) and how you go about implementing quality (“the approach”). And everyone (the CEO to the middle manager to the engineer) has different opinions. So a typical consensus has been to use a quality framework that is common in the industry and tailor it to meet the needs of the company. Every company that has more than one employee has some kind of policy or process (written or verbal) in place to maintain the quality standards that they think their customers expect from them.

But what tends to happen is that the company’s implementation of quality or discipline towards quality standards is not sufficient to meet the needs of their customers. Or conversely, it may be overkill resulting in wasted resources. While the former is more common or grabs more headlines (such as the recent Toyota fiasco), the latter situation can also be seen especially in critical industries as the military, healthcare and space exploration.

What is ironic is that the Agile movement is actually a response to more process. Agile values

  • Individuals and interactions over processes and tools.
  • Working software over comprehensive documentation.
  • Customer collaboration over contract negotiation.
  • Responding to change over following a plan.

Compare the left-hand side and right-hand side. It is very clear that Agile is trying to steer the software industry from being too focused on the journey and realize what is most important and that is (emphasis mine)

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Yup, Agile wants you to understand above all that the destination is pretty important. Of course, the rest of the principles do explain a better (easier/faster) way of meeting quality needs.

The importance of Agile is not that it helped create a better awareness of how useful quality is, but it provided a path to reduce the tension between meeting goals and ensuring quality. If you look at a heavy-duty process framework like CMMi, it is all about quality, but it is so cumbersome that companies either think that quality is too expensive or they implement way more process than they need and end up with expensive products that destroy business value. Agile offers a different way of thinking about quality that can be used by smaller teams thus enabling managers to make the right decisions about quality.

Posted in project management | Tagged , , | 2 Comments

The Case For Better Management

Posted on March 8, 2010 by Krishna

Stephen Forte makes what he thinks is a case against having “rock-star” developers in a team. You can read the post, but, in short, there was a programmer “John” on his team who picked coding arguments with the rest of the team. The final straw was that John burnt the whole team by directly moving his changes to production without going through the QA process and bringing down the site.

Stephen’s example is not very strong. A great programmer, by definition, should be someone who also understands and advocates good build and deployment practices. John was not such a person. It is also quite possible that a lower-grade programmer could have made the same error if they were under pressure from some management big-shot. You have to blame the incentives here.

In any case, these kind of train wrecks are easily preventable. An analogous example is locking the door if you are in the bathroom. Yes, people should knock before they try to enter it. But you cannot force everyone to follow such “best practices”, especially what is foremost in their mind is not the prospect of causing embarrassment to another person. Instead, what you can do is prevent someone from causing damage if it is really important to you.

So with respect to production servers, the simplest solution is to lock down access and grant it only to people who have a stake in following the process. This small group usually includes the system administrator responsible for the box, the project manager (or team leader, as the case may be) and the QA manager. All others, especially programmers, are more motivated to say that the work is done than to prevent any damage because of a mistake.

I am actually not in favor of providing access to the lead programmer, either, even if they are very experienced. The path should go through QA, who test the build or patch on a Test server that is as similar to the production server in terms of capability, environment and data as possible. One QA person is in charge of delivery and they sign off on releasing the build.

In a smaller organization, there will some overlap between roles, but do ensure that the person in charge of QA has the responsibility and sole authority for releasing code to production. That person should be independent of any influence by managers to speed up delivery of projects before adequate testing is done.

The other step is to be absolutely uncompromising about crossing management lines. There has to be one person (whatever the title) who has the authority and responsibility for accepting tasks for the development team. I am using those 2 keywords again, but what it means that only one person can accept a new task from someone outside the team, and once they accept it, they are fully responsible for it. This person maintains the backlog and if any manager wants to circumvent the hierarchy and talk directly to a developer, they will own it including breaking the schedule of other managers, crashing the servers and so on. And also, perhaps most important to them, that the task would be dropped without notice once the backlog manager learns about it.

Now, Stephen defines a rock star developer as “someone who, while talented, thinks that they are the ultimate guru and that everything should be done their way.” As I see it, you have hired a manager when all you needed was a programmer who can follow instructions. There was already a manager (you!) on the team. John doesn’t belong. His personality is such that he should be leading the team and swimming or sinking with the decisions he makes. But he probably doesn’t have the necessary resume to land that role in any company yet. In the meantime, he is a nightmare on the team because he tries to manage his peers. That is the real problem.

The difficulty in avoiding such hires is that during the hiring process, the rock star developer is sometimes indistinguishable from the talented, easy-going developer. Both are bursting with energy and ideas, some of which are actually pretty good too. You only learn the full extent of their behavior after a few weeks. The easy-going developer is comfortable with accepting authority and there is a give-and-take with respect to ideas. The rock star developer doesn’t understand why compromises are sometimes necessary and is quick to condemn differences in opinion as stupidity or evil. We all do the same to some extent, but the rock star developer’s condition is almost pathological.

The obvious route is to let the developer go, but if you don’t have a choice (in the short term), then one way to handle them is to divert them into tasks that require heavy lifting in research and development. They are now isolated from the rest of the team and the day-to-day grind, but they are kept extremely busy because they have to deliver something that works. This is something that I suspect rock star developers like, because they get to play the full court from analysis to recommendation. However, ensure that you have set the right parameters for accepting the outcome of the research so that you don’t get a recommendation that you will be forced to reject, thus exacerbating the problem.

Posted in project management, software development | Tagged , , | Leave a comment

Do The Basic Research

Posted on January 28, 2010 by Krishna

I fail to comprehend how someone can write this (emphasis mine):

Overdesign is also very common with databases. People get hung up on rules like “third normal form”. Sometimes when you over-normalize a database is [sic] makes it impossible to query the data later on. If your application is going to require reports, sometimes its better to design the database with the reports in mind. In other words, let the reports dictate how the data is stored.

This kind of advice is insane, ridiculous stuff. Take a minute and read what the third normal form means. Not following the third normal form means essentially having duplicate data in different places in your database creating a serious nightmare in maintaining data integrity. What you gain in reporting, you will lose when you start writing code to ensure that data is consistent everywhere.

Normalizing a database does not make it “impossible” to query data. If you have many tables because of normalization, work is harder because you need multiple joins to do the trick. But if you know elementary SQL, you can get it done easily. On the other hand, if you haven’t normalized properly, you have very silly problems. For example, in the Wikipedia example, to find out how many players were born on the 1st of January, you have to write code that does not count the birthdays of multiple players twice. In a normalized database, it is an extremely simple query.

It is ironic that the author talks about “overdesign” while falling victim to premature optimization. First, understand what normalization is supposed to do and how it helps you. Learn SQL or use tools that can help you get your data out easily. Profile your application and find ways to improve performance. And only if everything fails, then go for denormalization. And that too, only after understanding its downsides and how to prevent them.

Read my previous article on the same subject.

Posted in software development | Tagged , , | Leave a comment

The Delete Confirmation Functionality

Posted on January 13, 2010 by Krishna

Phil Haack writes about the lack of confirmation dialogs when deleting an item in the Netflix queue.

I have noticed something similar on the Amazon wish lists. It avoids an unnecessary click, but at the same time, allows you to quickly undo the action if you had accidentally clicked the first time.

This reminds me of one of my pet peeves: people who complain about the Delete confirmation dialog box for files. Generally, the person who makes this complaint “cannot imagine” how stupid the operating system architects and developers are there. The user wants to delete something. You have a Recycle Bin. Why doesn’t the operating system just get out of the way? And who reads the dialog box anyway? One complainer suggested that this was just a way for the developer to shift responsibility onto the user. Since the user clicked Yes, the programmer is no longer responsible if the user accidentally made a mistake. And the implication is that the programmer is lazier and needs to own the responsibility. Or something of the sort.

Obviously, I have no idea what the intention of the programmers were. But let’s assume that there was no confirmation dialog box and the second you clicked Delete, the file is deleted. That is great if you meant to hit the Delete key. But what if you had meant to hit the “End” key (to navigate to the end of a list of files) and your stubby finger pressed down both the Delete and End key. What would probably happen is that the currently selected file gets deleted, you navigate to the end of the file list and you don’t realize that your file has just been zapped.

But what about the Trash can, you say? The problem is that if you don’t know the file has been deleted, you may not bother to check its contents before emptying it, especially if you had been deleting other files. You may not even realize the mistake until days or weeks have passed and then even a disk recovery service may not be able to help you.

I elaborate on this seemingly minor issue because although user interface issues are more complex than they seem at first glance, because they don’t seem so complex, everyone has an opinion. Even those who have no clue about user interaction or the design choices that made a choice necessary, even if it was not the most optimal. This was best illustrated by a recent comic “How a Web Design Goes Straight to Hell” by Oatmeal Comics. As the author notes,

I actually had a client include their mother in the design process so that she could provide feedback and criticism. [...] You are no longer a web designer. You are now a mouse cursor inside a graphics program which the client can control by speaking, emailing and instant messaging.

It is a tough world out there for user interface and user interaction designers.

Posted in user experience | Tagged , | 2 Comments

Security Theater

Posted on January 12, 2010 by Krishna

Bruce Schneier (the author of “Applied Cryptography” and other books) explains why security theater (where security measures do not do much to improve real security) has its benefits:

Tamper-resistant packaging for over-the-counter drugs started to appear in the ’80s, in response to some highly publicized poisonings. As a countermeasure, it’s largely security theater. It’s easy to poison many foods and over-the-counter medicines right through the seal — with a syringe, for example — or to open and replace the seal well enough that an unwary consumer won’t detect it. But in the ’80s, there was a widespread fear of random poisonings in over-the-counter medicines, and tamper-resistant packaging brought people’s perceptions of the risk more in line with the actual risk: minimal. [...]

We make smart security trade-offs — and by this I mean trade-offs for genuine security — when our feeling of security closely matches the reality. When the two are out of alignment, we get security wrong. Security theater is no substitute for security reality, but, used correctly, security theater can be a way of raising our feeling of security so that it more closely matches the reality of security. It makes us feel more secure handing our babies off to doctors and nurses, buying over-the-counter medicines and flying on airplanes — closer to how secure we should feel if we had all the facts and did the math correctly.

The relation to the business world is “management theater”. There are these tons of management processes that don’t do anything to improve the success of the project or prevent its failure. Instead, they are to reassure stakeholders that “proper” management is in place.

The lesson from Bruce’s article is that even though we may want to throw all of such processes out the window, they may actually have an use. Instead of customers becoming tense and worried, and upper management trying to micro-manage the project, some of these processes may convey that the project is truly under control and the project team can be trusted. It can also reduce finger-pointing and place emphasis on improving items that hinder the project.

The tricky thing is to know what process to keep in and what to take out. What Bruce’s article suggests is to ask stakeholders or understand them to see what keeps them comfortable. For example, they get project updates in a specific format at regular intervals. Or the build, testing and deployment process is done in a specific way and is visible to them. The customer may not even read the report, but the fact that they have it keeps them happy.

Posted in business management | Tagged , | Leave a comment

Outdated Catchphrases

Posted on January 4, 2010 by Krishna

A hilarious take from Ron Rosenbaum:

But don’t call it outside the box anymore, please. By now, the injunction to “think outside the box” has become inside the box airline-magazine management-guru cliché. Please, some of you should get back into the box, please, and take your quirky Power Points with you. What about thinking outside outside the box? Not outside the box but not inside the box again, either. Transcend the box.

I am sure some of you remember this classic puzzle. The first time you see the puzzle, learn the solution and hear the words “go outside the box”, it is very powerful. But after a few times, it sounds banal. And when you hear it from someone who is totally uncreative, you actively start hating the phrase.

Unfortunately, that is the fate of all such cute catchphrases or ideas. Most of the best ones have been ruined by overuse in popular culture. And others have been tainted by people who have forgotten  how human beings talk.

Things like, “Give your 110%“, “Work smarter, not harder“, etc. are good concepts, but are now hated management clichés because too many bad managers have used them to absolve themselves of their responsibility in managing projects better. This also goes for observations such as Parkinson’s Law and the Peter Principle. When they are misunderstood, they can be very harmful in the hands of a bad manager with too much time in his hand and very few brain cells in his head.

Incidentally, have you noticed that good managers tend to be the most productive and bad managers the most destructive when they are least busy? More time for good managers means that they have been able to delegate their tasks well and they have more time to spend at a higher level (learning, analysis and planning). A bad manager feels too insecure to be seen with free time and so they start micro-managing or implementing something without understanding it well.

Why do bad managers use hated catchphrases so frequently? I guess it has to do with intellectual laziness. Poor managers may work very long hours, but they all never seem to have any time to sit and evaluate whether they are doing the right thing. Using management speak makes them feel more important and wiser, giving them a false sense of control and correctness. Plus, the authority inherent in these phrases and ideas makes them very convenient to beat down ideas from the underlings.

On the same topic, some good stuff from Malcolm Gladwell (emphasis mine):

[...] “The Dark Side of Charisma.” [...] argued that flawed managers fall into three types. One is the High Likability Floater, who rises effortlessly in an organization because he never takes any difficult decisions or makes any enemies. Another is the Homme de Ressentiment, who seethes below the surface and plots against his enemies. The most interesting of the three is the Narcissist, whose energy and self-confidence and charm lead him inexorably up the corporate ladder. Narcissists are terrible managers. They resist accepting suggestions, thinking it will make them appear weak, and they don’t believe that others have anything useful to tell them.

Posted in business management | Tagged , , | 2 Comments

2009 – The Best and Worst Books I Read

Posted on January 3, 2010 by Krishna

As I did last year and the year before that, I am here again with the list of best and worst books I read in 2009. To be clear, these are the books I read, not the books published in 2009. This year, I read over 90 books: Includes a high percentage of fiction, but does not include a few (bad) non-fiction books I returned before completing. So here goes:

Best Books I Read in 2009

  • The Big Switch, by Nicholas Carr: How cloud computing will reshape the IT infrastructure of companies, big and small. Nick Carr compares this to the the transformation of companies in the last century from using internal power generators  to getting their power from a grid. He paints a scary picture of how cloud computing will result in greater unemployment and privacy intrusions. I don’t fully agree with all his predictions, but he raises some important concerns.
  • The Drunkard’s Walk, by Leonard Mlodinow: A beautiful book on statistics – Who said math couldn’t be fun? At the same time, this is a serious book that exposes some common misconceptions about probabilities and expectations.
  • The Business of Software, by Michael Cusumano: A great example of why you should read books instead of solely relying on piecemeal wisdom in articles. Cusumano gives us a wide overview of the software business and what companies need to do to survive and thrive in the long-term. Instead of only looking at the outliers (giants like Microsoft or Google), he uses case studies of small to mid-size companies to make his arguments.
  • Code, by Charles Petzold: The author has written a beautiful book for beginners to computer hardware. Although I was familiar with the contents, it was still enjoyable to see how Petzold explained the concepts. If you want to start anyone on understanding computers, this is the book to hand them.
  • Creative Capitalism, by Michael Kinsley, et. al.: A bunch of essays from Bill Gates, Warren Buffett and several economists about if and how capitalism can be leveraged to solve some of the greatest problems (poverty, disease, under-development) facing humankind in our age.

Honorable mentions go to Orbiting the Giant Hairball (Gordon MacKenzie), Buy-ology (Martin Lindstrom), Common Wealth (Jeffrey Sachs), and Why We Make Mistakes? (Joseph Hallinan).

My favorite author for 2009 is Scott Rosenberg, author of “Say Everything” and “Dreaming in Code“. Why don’t my favorite authors find a place in my favorite books? The answer is: why does the Best Director lose out on the Best Picture award?

Worst Books I Read in 2009

  • The Inmates are Running the Asylum, by Alan Cooper: This is a seriously misguided book that makes programmers the scapegoats for every problem associated with software. Whatever good  points there are have been overshadowed by the incredible vitriol and hatred. Read my detailed take.
  • Everything You Knew about CSS is Wrong, by Rachel Andrew, Kevin Yank: This is a special award for the most deceptive book title of the year. Instead of a detailed book about CSS, all it does is provide a different method for creating a grid in CSS.
  • A Little History of the World, by E H Gombrich: An older book supposed to be a “classic” on world history, except for the fact that it doesn’t consider many historical events outside Europe. And the prejudice against other cultures and religions doesn’t help, either.
  • The Creative Habit, by Twyla Tharp: A semi-autobiography disguised as a self-help book. The best I can say about this book is that you could pick up a few pointers about generating ideas after wading through the rest of the fluff.
  • ENIAC, by Scott McCartney: Intrigue sells better than technology. At least, that seems to be the motto of the author who decided to highlight the politics and power games surrounding the development of the first electronic computer instead of elaborating upon the technical details and challenges.

Other disappointments included Donald Norman’s famous “The Design of Everyday Things” that turned out to be very outdated. I learnt that it is crazy to obsessively read all of Seth Godin’s past books as they seem to mostly say the same thing over and over again with different examples; it is perhaps time for him to write a full-fledged book. Same goes for Scott Adams: Dilbert just gets tiring after a while.

As for fiction, my hero, P G Wodehouse, turned out to have feet of clay. Having read several of his books last year, I can say that while Wodehouse has a few enormously hilarious books, it is clear that there was a marked decline (repetition and loose plots) towards the end of his career. The Albert Uderzo-only Asterix books are terrible as are the first two non-color Tintin books. And the less said about “Netherland”, the better.

Posted in reading | Tagged , | 5 Comments

Counterproductive Hiring Practices

Posted on December 15, 2009 by Krishna

I am agnostic about pair programming. I believe that having strong programmers and a good code review process offers at least as much benefit as (if not more than) full-fledged pair programming, but if it is working for someone, I don’t see any reason to object. Researching which brought me to Obie Fernandez’s strange self-congratulatory article on pair programming.

Apart from the evidence-less accusations about what “most” software developers, managers and firms seem to do, it also has some silly ideas about hiring good developers. Read:

The best way to hire talent is to drop them in actual work situations for at least a week and see what happens. [...] Our candidates spend their interview week rotating on actual production code, pairing with the same people they’ll be working with if they’re hired. Everyone gets a say in whether to hire a new recruit, and hesitance from a developer that actually paired with them means they do not get hired.

I don’t understand in what universe a talented programmer is going to take a week’s worth of leave to work as part of an interviewing process for an obscure company. Maybe a desperate, unemployed programmer? Since the best programmers are already attracted and hired by the big firms (Google, Microsoft, Facebook, etc.), is this any way to recruit them away?

This is simply a case of “don’t know what is missing“. The company simply doesn’t realize how drastically it has shrunk the pool from which it can hire and assumes that it has the best possible developers.  There is some benefit to doing your homework before hiring someone, but this is a practice that has gone too far into the other direction.

Posted in business management | Tagged , | 6 Comments

The Danger of Stories and Anecdotes

Posted on November 30, 2009 by Krishna

It was fun reading Michael Dubakov’s take on technical debt through his story of Arthur and the princess. But then the questions started. The competition was rigged from the beginning, wasn’t it? After all, Arthur made it to the final round, didn’t he? What if the weather had been perfect for the next few months?

Illustrating a concept through stories and anecdotes makes an article more interesting and more likely to be read. But it is a tactic that is fraught with risk and can, at times, flirt with deception.

To begin with, a story is obviously fiction and you can make up whatever you want to. This means that you also hand a licence to believers in the opposing view to create their own stories which end differently. So a person who believes in quick-and-dirty coding can make up a story where careful planners starve to death while the risk-taker wins and lives happily ever after.

Also, stories can be pretty condescending. The worst examples I have come across are the Ken Blanchard books like “Who Moved My Cheese?” and other imitators. The writer has an agenda and he/she manipulates the shallow characters in the book to further it. Few non-fiction writers have the skill to develop a compelling story and meaningful characters. An example to the contrary being “The Goal” by Eliyahu Goldratt.

Anecdotes are, at least (or hopefully), truthful. But every such tale represents a single data point. They do not tell the whole story. They lend themselves to cherry-picking and presenting a view completely opposite to reality. Writers need not be malicious to do this; only the incidents that promote their ideas may stay in their memory.

One legitimate use of anecdotes is debunking a generalized statement. For example, if someone says, “X is always true” and you remember an incident to the contrary. But this one application is usually exploited to create FUD. We see that in newsrooms, where although the crime rate is declining, crimes are reported as though there is a huge crisis.

Since writers, including me, like to use stories and metaphors because it makes our writing richer, readers have to be on alert. Writers themselves may be true believers in something and may not realize how they are trying to manipulate their readers.

Posted in writing | Tagged , , | Leave a comment