The Wit and Ramblings of David Giard - Books
Demanding rigidly defined areas of doubt and uncertainty

It has been almost a decade since I first learned C#. It didn’t take me long to become productive in this language; but years later, I am still uncovering its secrets. There are two reasons for this:

1. C# is a relatively complex language and new features are added with each release. There is a lot to learn
2. In many cases, C# offers multiple ways to accomplish the same task and it’s not always obvious which way is best for my project.

In Effective C#, 2nd Edition, Bill Wagner attempts to demystify C# by explaining much of the inner workings of the language and by providing specific advice points to improve your coding.

The book assumes a basic understanding of C# syntax. It builds on this understanding in two ways:

1. Explaining the implementation details of the language
2. Providing advice on how to use the language and the .Net libraries in your coding.

The second edition of this book includes new features introduced in C# 3.0 and 4.0, such as lambda expressions and LINQ.

The book is split into 50 chapters and each chapter advises developers on a specific coding preference. Wagner backs up his advice with an explanation of the inner workings of the C# language. Among the questions that Wagner answers are:

• What is the difference between readonly and const and which one should I use and why?
• What new C# feature reduces the need for multiple overloads?
• When and how do I need to explicitly dispose of objects?
• What does it mean for a variable to be statically typed as a dynamic variable? Does that even make sense?

I learned something new in nearly every chapter. Some chapters shed more light on topics that I thought I knew well. Other chapters introduced me to concepts about which I knew very little. And a few chapters contained information so complex that my head began to hurt (I'm looking at you, IDynamicMetaObjectProvider).

With 50 chapters of solid advance and concise explanations, everyone beyond a beginner level in C# can benefit from this book.

You might think that full-color illustrations would make very little difference in a technical book.

But  Beginning JavaScript and CSS Development with jQuery by Richard York focuses so much on user interfaces that the added color makes the samples more clear. When the author lists code to change the color of a paragraph, the illustration shows the new and old colors to drive home the concept.

York starts with the basics of jQuery – selecting elements on a page and applying styles dynamically – and moves progressively into more advanced topics, such as making Ajax calls and accessing the jQuery API. He devotes about a third of the book to jQueryUI, a library that contains controls designed to build rich, interactive web interfaces without the need for a lot of code.

York explains the challenges inherent in developing applications with Javascript (the need code to different Document Object Models for each browser) and how jQuery addresses this by providing a single programming model that abstracts away the different browser DOMS.

The book is filled with examples, showing the HTML, CSS and jQuery demonstrating each point. You can read/copy these from the book or download them from the Wrox site.

This book is aimed at someone with experience in HTML and CSS, but little to no Javascript or jQuery knowledge. For those just getting started in jQuery this is an easy to follow book where you can learn the concepts and quickly become productive.

It’s no secret that software developers, managers and analysts do a poor job estimating projects. Few IT projects complete within the time they are estimated and far more go over the original estimate than under it.

Steve McConnell knows how difficult estimation can be His 2006 book Software Estimation is subtitled Demystifying the Black Art.

Developing reasonable estimates of software projects may not be a black art, but it does cause problems and most people fail at it for a variety of reasons.

McConnell refers to estimation as an art, not because it has no basis in science, but because formulas don't tell the whole story. Experience and difficult-to-measure inputs are required to generate a complete estimate. And even then, you may still get it wrong.

When McConell lists sources of estimation error (subjectivity, missing tasks, unwarranted optimism, excess precision), it's startling how many of those factors I have experienced or contributed in my own career.

The author provides various methods for creating an estimate and guidance on improving the accuracy of your estimates. Among his advice is:

• Base your estimates on something you can measure - preferably historical data on similar projects in your own organization. Estimates based on measurable data are far superior to those based on subjective criteria.
• Estimates are never precise (they're not called "exactimates"). Present estimates as ranges and don't include more significant digits than your inputs can justify.
• If possible, get effort estimates from those who will actually perform the work. Developers vary in how quickly they can accomplish a given task - sometimes that variance is in orders of magnitude.

If part of your job includes estimating software projects, this is an essential book to guide you. Like most of McConnell’s books, I recommend it.

The Elements of Style by William Strunk Jr and E.B. White changed my life.

In 1919, E.B. White was a student in William Strunk Jr's Cornell English class. The course textbook - written by Strunk a year earlier - impressed White enough that he decided to revise and expand it 40 years later.

While Strunk's version focused primarily on rules of proper English grammar, White added sections on writing style.

White argued that writing can be grammatically correct but poor quality, if it lacks good style. In his revised edition, White established guidelines by which a writer can improve his or her writing style.

The book has been revised several times over the years as the English language and the audience have changed and evolved.

The major points of the Elements of Style are

• Know the basic rules of grammar. Be aware of the most common errors of grammar and spelling.
• Tell your story in a clear and straightforward manner. The message is more important than the style.
• Be Concise. Wasted words dilute your writing.
• Excessive adjectives, adverbs and qualifiers detract from your message. Eliminate them.
• Choose established usage, before deviating

Most of these rules can be broken, White tells us.

The Elements of Style is often criticized because many great writers ignore this book's advice. But White does not claim to preach dogma: He provides guidelines that will improve most writing.

But we should understand the rules that we are breaking and we should break them for good reason.

If you do any writing in English, you will benefit from this book. At less than a hundred pages, the time investment is small but it packs more information than much larger books.

This is a book that I read every few years because it reminds me of the power of strong, concise writing.

Interest in F# has risen dramatically with the release of Visual Studio 2010 and Microsoft's decision to include this language with this product.  Many of us are scrambling to understand this new language and how it relates to our software projects.

F# is a functional language, which means that it focuses on giving developers the ability to create functions that consistently return the same value, given the same inputs. It does so by discouraging mutability in its language constructs, thus minimizing side effects that can alter state from one call to the next.

Chris Smith's book Programming F# provides an introduction to and an overview of this language. Because so many of the constructs are foreign, this book can be a bit overwhelming - particularly Chapter 2, which quickly introduces many of the language constructs of F#.

But Smith brings it together after pushing through the language details. He goes through the basics of functional programming; then compares it to imperative programming, showing how you can implement either style using F#. He follows with a discussion of object-oriented programming and its relevance to F# (it is a key to allowing F# programs to interact with programs written in other .Net languages).

The book is filled with examples to illustrate the points made. If you are new to F#, Programming F# is a good book to get you started with the language.

What I like about Paul Kimmel's LINQ Unleashed for C# is that he does not rush into explaining LINQ. Before explaining LINQ, Kimmel explains the new technologies that make LINQ possible.

He walks the reader through anonymous types, type initialization, extension methods, the yield return statement, lambda expressions, and closures - all features that were introduced in C#3.0 - before explaining how each of these features makes LINQ possible.

After building up to it, Kimmel steps through the syntax of LINQ, providing numerous code examples.

He begins with syntax to all implementations of LINQ; then dives into more detail about the major LINQ implementations: LINQ to SQL, LINQ to Objects, and LINQ to XML. In each section, he provides numerous helpful samples.

When I first opened this book, I was new to LINQ (Language Integrated Query) and had no grasp of how it works. This book got me up to speed. I recommend it for anyone learning LINQ.

Like most statistical measurements of large groups, the success of people in a given population usually forms a normal distribution or "bell curve". In other words, most people fall at or near the average level of success; and as we move further above and below the average, fewer and fewer people appear at each level until the number approaches zero far above and below the average.

But some people fall well outside the boundaries predicted by the normal distribution. These people are outliers.

In his book "Outliers", Malcolm Gladwell is primarily concerned with those outliers who excel far beyond the level expected. These are intellectual geniuses and musical prodigies and world-class athletes who achieve great success.

Becoming an outlier takes talent and hard work - a lot of hard work: 10,000 hours of dedicated practice, according to Gladwell.  For example, the Beatles owe their success in large part to the fact that they performed 8-12 hours a day for 2 years at the clubs in Hamburg, Germany, allowing them a chance to perfect their craft before they recorded their first hit records.

But Gladwell insists that enormous success takes more than talent and hard work. It takes luck. And that luck sometimes follows measurable patterns and those patterns can be predicted.

As evidence, he points to birth dates as a major factor in the success of many outliers. Bill Gates, Paul Allen and Steve Jobs were born within months of each other; Of the 75% richest people in history, 14 were born in the United States between 1831 and 1840; and the vast majority of elite Canadian hockey players were born during the first half of the year.

He then explains reasons why something as seemingly arbitrary as a birth date would affect one's chance at extreme success. In each case, he presents a plausible explanation of the cause and effect. Canadian hockey players born in January, for example, tend to be placed in the same league as the much younger players born in December of the same year. At a very young age, this can be a huge advantage, so the older, bigger, stronger January-born athletes tend to dominate the less mature December-born players. As the stronger kids stand out more, they get picked for the better leagues, where they receive superior instruction and more practice time (making it more likely they will be able to put in 10,000 hours of practice before adulthood).

Just as talent and hard work alone will not guarantee success, neither will lucky circumstances. But these things improve one's chances - sometimes drastically.  Not all Canadian hockey players born in January make it to the NHL. But almost none of those born in December do.

Gladwell's case studies are very interesting and very plausible. He supports his hypotheses primarily with anecdotal evidence. But he supplies enough statistics to support his conclusions.

These seemingly random factors are often predictable, so it is possible to modify our behavior and increase our chances at great success. Some of them (month of birth, for example) are beyond our own control; while others (year of birth, are only known to be success factors later on), so it's difficult to modify all our behavior.

Outliers challenges the notion that people achieve great success solely through talent and hard work. Outliers is an interesting study of his findings and worth reading.

I began reading Agile Principles, Patterns and Practices in C# by Robert C Martin and Micah Martin after a friend recommended the chapters on pair programming.  My friend was right, of course. The Martins not only decribed pair programming but included an entertaining script of two developers pairing on a programming problem.

But, as I dove deeper into this book, I found a wealth of other information.

The book begins with a section on agile development, defining some basic terms and concepts recommended practices. It follows with a detailed section on good design practice. This second section is the most interesting, as it describes the famous SOLID principles. SOLID is an acronym for a set of good design practices:

S=Single Responsibility Principle: Each class should serve only one purpose and have only one reason to change.
O=Open-Close Principle: Classes should be open for extension but closed for modification
L=Liskov Substitution Principle: It should always be possible to substitute a derived class with its base class
I=Interface Segregation Principle: Interfaces implemented by a class are defined by the client objects that use that class; a class should implement a separate interface for each client that calls it.
D=Dependency Inversion Principle: To maintain flexibility, you should write code that depends on abstractions, such as interfaces.

Next, the authors present an overview of Unified Markup Language (UML), a graphical language used to describe software designs and requirements. Common UML diagrams and shapes are described and the author offers opinions of which ones are most useful and when to best use them.

The last half of the book is a case study of a Payroll System in which the authors use examples to illustrate the concepts introduced in the first half of the book.

Although C# is included in the title, the book does not focus on C# and almost none of the concepts are specific to any particular language. All the code examples are in C#, which makes it a bit more accessible if that is your strongest language.

The book is filled with lots of information and good advice. For example, the authors recommend an iterative approach to writing software, a test-first approach to development and encourage developers to refactoring their code frequently.

Whether you read all of Agile Principles, Patterns and Practices in C# or pick through the sections of interest, you will benefit from this book.

You could start at the beginning and read all the way through Windows Server 2008 R2 Administration Instant Reference by Matt Hester and Chris Henley. Part 1 of the book of the book ("Getting Started") walks the reader through planning, installing and upgrading the operating system, while subsequent sections dive into details about specific areas of the software.

But a more reasonable approach is to open to the section on which you are working today. Each chapter is structured so that you can dig into the detail you need. Each topic begins with an explanation of concepts and definitions of key terms. This part is critical for someone like me, who doesn't spend his days managing servers. Experienced administrators may skip this section and jump to the detailed explanations of how to use and configure each feature of Windows Server 2008 R2. Basic functionality is described first, followed by more advanced features.

A section on Active Directory, for example, begins with a description of built-in groups, followed by a description of custom users and groups and how rights are granted. After establishing these basics, the author describes how to use Active Directory to manage groups, users and rights and how to configure this in Windows Server.

Hester and Henley write in a clear, concise style that simplifies everything they describe. Step-by-step instructions are amplified by screen shots.

The smaller dimensions of the book make it fit easily into a laptop bag, despite the 500+ pages of text.

This is a solid book for a full- or part-time network administrator to keep on hand for a quick reference or for a more detailed look into important concepts of Windows Server.

Official Book site

Complexity is the Enemy! 

This is the message driven home repeatedly by Roger Sessions in his book Simple Architectures for Complex Enterprises. 

Sessions recommends tackling a complex enterprise architecture by identifying the subcomponents of a complex system and dividing that system into autonomous subsystems. He refers to these subsystems as Autonomous Business Capabilities (ABCs) and the process of dividing them as a Simple Iterative Process (SIP).  

Before describing how to approach this process, Sessions presents a mathematical proof that subdividing a complex system into a set of subsystems reduces the complexity of the system as a whole. This seems intuitive to many of us, but the mathematics allow us to be more forceful in our commitment to this process. The mathematics is relatively simple (nothing beyond high school math) and he even recommends training team members in this mathematics before beginning any SIP.

A large part of an Enterprise Architect's job is to define the optimal way to partition the complex system. By applying mathematics to his model, he removes the emotions that so often dictate how a project is broken up.

The process of splitting a complex system into appropriate subsystem isn't overwhelming, but it is critical to managing complexity. According to Sessions, Each ABC should contain only elements that relate to one another; and the elements of one ABC should not relate directly to or communicate directly with any element in another ABC. Once partitioned, each ABC should be roughly the same size, although it is possible to split a subsystem further into sub-subsystems. It is also critical that communication between each subsystem take place only at a few clearly-defined points.

If this sounds like a recipe for Service Oriented Architecture, this is no coincidence. Sessions concludes his book with recommendations on moving from business partitions (ABCs) to software partitions, which he describes as "fortresses". These software partitions follow many of the same rules as ABCs created with the SIP, so making this transition is straightforward.

This is a good book for anyone who aspires to be an Architect (Enterprise or otherwise) and wants to apply a systematic approach to managing complexity.

Microsoft ASP.Net MVC (aka "MVC") is a new framework from Microsoft designed to encourage loose coupling between the user interface and the data layer of a web application. With MVC, an application is logically divided into the Model (the data), the View (the user interface) and the Controller (code to retrieve and manipulate data before passing it to the View). This framework makes it nearly impossible to add business logic (or any code for that matter) to the UI layer; Business logic in an MVC application belongs in either the Model or the Controller. MVC allows for greater separation of concerns, more control over the HTML output and easier unit testing of a greater percentage of your code.

Professional ASP.NET MVC 1.0 by Rob Conery, Scott Hanselman, Phil Haack and Scott Guthrie describes the framework, how to use it, and how to exploit these advantages.

A significant part (about 40% of the text) of this book can be downloaded free. Chapter 1 - the free download written by Microsoft VP and cyber-celebrity Scott Guthrie - describes an ASP.NET MVC application called 'Nerd Dinner'.  This is the chapter I spent the most time on. I used Nerd Dinner as a model to build my own MVC application, striving to understand why the code was written as it was and how the framework was used. For me, this was the most useful part of the book.

This is not to say that the rest of the book is useless - It was very informative. I especially liked the chapters that dove deeper into explaining the Routing Engine, the Controllers and the Views. These chapters weren't comprehensive enough to be a definitive reference, but they were clear and concisse and I learned the flexibility of this framework and alternative ways to use it.

Other chapters describe how to use JQuery and Ajax to make MVC applications more dynamic and visually appealing. The authors devoted two chapters to testing because this is one of the major benefits of MVC.

The final chapter describes how to integrate MVC and the traditional web forms framework into a single application. I appreciated this because so much of my work is modifying existing systems.

My recommendation is to download and read the free chapter of this book before deciding whether to invest the 50 bucks on the larger dead tree version. This will give you a better perspective on the framework and you will make the rest of the book more relevant. If your goal is simply to evaluate this framework or get exposure to it, this chapter may be sufficient.

But if your interest is piqued by Nerd Dinner, the remainder of this book is a good start in learning MVC.

Think big; act small; fail fast; learn rapidly.

These are some of the lessons from Tom and Mary Poppendieck’s book Lean Software Development – An Agile Toolkit.

The Poppendiecks take what they learned from Lean Manufacturing (many of which were originated with the pioneering work of Toyota Motor Company) and apply these lessons to software development.

They deliver advice in the form of 22 “tools” that can make a team or project more lean. Related tools are grouped together into chapters.

The authors recommend that organizations define, find and eliminate waste wherever it occurs in a process. Examples of waste in software development include defects, waiting, extra features or processes, and any non-essential activity. To assist finding waste, they recommend Value Stream Mapping - a technique in which one lists in sequences all the steps from customer request to delivery and estimates the time to completion of each step and the wait time between each step. This technique often makes bottlenecks obvious so that they can be reduced or eliminated.

Many of the tools in this book overlap. For example, iterations and feedback are listed as separate tools, but shorter iterations allow for more frequent feedback to the development team. Short iterations also expose design problems more quickly sot that the can be corrected early in the development cycle at a lower cost.

Much of the authors’ advice seems counter-intuitive. For example, they recommend against detailed planning at the start of a project and attempting to optimize every part of a multi-part project.

A popular approach among software project managers is to create in advance a detailed plan of every step in the design, development and deployment process and to estimate each step. To do so, you need to know a specific scope of everything you will build. This makes sense as a risk-reduction strategy, until you consider that environments, requirements, priorities and people often change while software is being developed. A rigid plan created up front often requires an aggressive change control process to alter that plan in any way. And for long-term projects, the changing landscape almost always forces changes to the design. Also, when users know they will only get one chance to request features, they tend to ask for far more, so scope tends to get bloated when projects are planned in this way. A better approach is to re-evaluate priorities periodically throughout the development process and keep focused on the top priority features that have not yet been implemented.

Complex project can and often should be split into a number of smaller phases or tasks. This helps to simplify the complexity. Many managers then strive to optimize each phase of the project, assuming that this goal will lead to overall optimization of the project. The Poppendiecks advise against this goal because optimizing some phases may cause a bottleneck in your overall project, thus slowing down the project as a whole. A buildup of code waiting to be tested, for example, represents waste that should be eliminated. It is best to look at the system as a whole when setting optimization goals. Optimizing each part ignores the interaction between these parts.

The book finishes with practical advice to get started making your team and process more lean.

Lean Software Development - An Agile Toolkit is a clearly-written, thoughtful book and anyone involved in software development projects can benefit from reading it.

Steve Krug’s Don’t Make Me Think is a great book, not only for what it contains, but for what it does not contain.

At a couple hundred pages (most of which are filled with large graphics), Krug is forced to be concise in order to deliver his message. There is no room for irrelevant data in so little text. Happily for the reader, he succeeds brilliantly.

“Don’t Make Me Think” is not just the title of this book - It is the single most important point Krug makes about web usability design.

Throughout the book, he emphasizes that a good user interface should be self-evident. A user seeing a web page for the first time should not have to wonder what the page is for or how to use it.

He provides many examples to illustrate his points – most from actual web sites. Krug holds up Amazon.com as an example of a site that is doing many things right, making itself intuitive for the users. It’s tough to argue this point, given Amazon’s success and enormous growth over the years.

According to Krug, most web designers make the mistake of assuming that visitors to their site will read everything on each page presented to them. The reality is that most visitors quickly scan a page, searching for anything that looks relevant to them. When they find something that seems useful and clickable, they click it. When they actually find something useful, they stop looking.

Because of this behavior, web designers should focus on simplifying their page layout and draw the reader’s eye to the most important parts of the page that support the most common activities. They should provide clear, self-evident labels for the items on their pages: there should be no confusion what each item is for and what will happen if a user clicks on it or otherwise interacts with it.

But following his design advice is not sufficient. Krug also recommends recruiting and observing testers to use your web design. Watch how they interact with the pages; note the pages that they struggle to learn; document unexpected behavior.  A designer does not always think like an end user and users often react in unexpected ways. This type of testing is a good way to learn how end users perceive and interact with your site.

Check out this book if you want a quick way to improve the usability of your web sites.

Cliff Atkinson's Beyond Bullet Points proposes a radically new approach to creating presentations based on Microsoft Power Point.

Atkinson provides a template (available for download); an outline that splits a presentation into lengths of 5, 15 and 45 minutes; and an abundance of advice on improving your presentations.

After reading the book, I discarded the template and the outline but I embraced many of his ideas.

Here is some of the book's best advice:

Allow your presentation to tell a story.
The first presentation I did after reading this book included a story about consultants Juan and Amal, who had nearly identical skills and accomplishments but received very different performance reviews. Most of my presentations are instructions on how to use software, which doesn't lend itself well to a story format. If possible, however, I try to weave a story into the presentation.

Minimize the text in your slides.
Atkinson recommends eliminating all bullet points from every slide. The only text on each slide should be a headline. I haven't gone that far, but I have drastically reduced the amount of text on each slide. When I open an existing deck, I move much of the slide text into the Notes section. This simplifies the presentation, but keeps the text with the slides when I distribute them to users. During presentation, I make the former bullet points part of my verbal presentation, rather than something the audience reads off the screen. This keeps the audience's focus on me, rather than on the screen.

Use simple graphics
A simple graphic communicates an idea visually. I have been replacing the bullet points in my slides with a headline and a single photograph that relates to the slide topic. The slides become more interesting but less distracting.

Rehearse your talk
I already knew this but the book's reinforcement helped remind me how important it is to be familiar with one's material. Nothing achieves this goal like a couple dry runs through your presentation. Ideally this should be in front of other people (to provide feedback) and in a room similar to the one in which you will be presenting; however, filming your presentation and reviewing it yourself is also very helpful.

I have not bought entirely into the Beyond Bullet Points approach. But I have internalized many of the ideas in this book and my presentations have improved as a result.

Link: Beyond Bullet Points Online

Lynnne Truss is a stickler - a stickler for proper punctuation. 

I don't know if she wanders the streets with a marker to add missing apostrophes - such as on posters for the movie Two Weeks Notice; or with white stickers to conceal extraneous punctuation - such as in a store signs that read "Boat Motor's", but I know that she is tempted to do so. I know that it pains her to see such misuse of common punctuation in public places. She agonizes each time she sees "its" and "it's" misused.

She put together "Eats, Shoots & Leaves" - a small volume designed to clarify the proper usage of punctuation in the English language and to pursuade us that it is important. 

Like Ms. Truss, I agree on the importance of punctuation, particularly in public or professional communication; but I don't always know the correct rules, so her advice is useful.

The book devotes a full chapter to the use and abuse of the apostrophe; another to the comma; a third to the dash; and so on. For each punctuation mark in question, Ms. Truss lists the proper usages of that punctuation and some common, and annoying, violations of those rules.  For example, her book lists 17 distinct uses for the comma.

It’s a difficult task because punctuation rules are sometimes vague and open to interpretation; and because the rules are often broken by respected writers; and because the rules change in a living language like English. 

But Truss does her best to clarify the vagaries and to evangelize the static, unambiguous rules. It's important because the meaning of a sentence can change dramatically, depending on the punctuation: "Extra-marital sex" does not mean the same as "Extra marital sex";

The poor punctuation of "Eats, Shoots & leaves" (the title; not the book) misrepresents the characteristics of a panda. An extraneous comma suggests that a panda employs firearms after its meal and before its exit. Correctly punctuated ("Eats shoots and leaves"), the phrase describes a panda's favorite meal.

Most of Ms. Truss's advice does not sound like a textbook. Regarding comma usage, for example, she dictates the rule: "Don't use commas like a stupid person". What she means is that one should step back and read a sentence to verify that the punctuation conveys the correct meaning. 
For example, the sentence
"Leonora walked on her head, a little higher than usual."
is grammatically correct, but probably not what the author intended.

Despite her passion for the topic, her style is light and engaging. I laughed out loud several times while reading this short volume. She parenthetically refers to Gertrude Stein as a "strange woman" (presumably because she disagrees with nearly every opinion Ms. Stein holds on punctuation); and she once described a long, over-punctuated sentence as exhaustedly slipping into a comma.

I really enjoyed this book and will keep it on my bookshelf beside Strunk and White's excellent The Elements of Style because it is concise, accessible and extremely useful.

Edward Tufte has spent a lifetime turning data into pictures and studying the best way to do so.

In his first (self-published) book The Visual Display of Quantitative Information, he describes what makes an excellent graph or map. 

Not all data sets are good candidates for charts.  For small data sets with exact values, Tufte recommends using tables.  However to compare values or present many pieces of data simultaneously, a graph is far superior.  Graphs, Tufte asserts, are most useful when showing complex data and displaying trends or observations that are not immediately obvious when the data is displayed in tabular form.  An excellent graph is one that is clear, precise and efficient - that is it "gives to the viewer the greatest number of ideas in the shortest time with the least ink in the smallest space."

Tufte provides some advice to accomplish this graphical excellence.  He introduces the concept of "Data-Ink" ratio.  This is the amount of information conveyed by a chart, relative to the amount of ink required to print that chart.  Generally, a graph can be improved by increasing its Data-Ink Ratio.  This can be accomplished by erasing non-data ink, such as unnecessary gridlines and labels; by erasing redundant data; and by labeling data directly, rather than forcing users to look up information in a legend.

Related to the Data-Ink ratio is his push for high data density - graphics that have maximum data per page, maximum data per square inch, and maximum data per amount of ink used.  As long as a graphic does not appear confusing, cluttered or overwhelming, you should pack as much information as you can into it.

Tufte warns against "chartjunk", his term for irrelevant text, lines, pictures or other decorations that contain no actual information.  This is ink that can be erased from a chart without reducing the amount of information in the chart.  Many graphs contain pictures, 3D effects and colors that don’t relate to the data.  Rather than enhancing the user’s understanding of the data, this “junk” distracts the user’s attention from the data, making the graph harder to understand.  Erasing chartjunk increases the Data-Ink ratio, which should be the goal of every designer of data graphics.

I appreciate that the book provides numerous examples of both the right way and the wrong way to represent data visually and that most of these examples came from real-world publication.  Tufte pulls no punches in his criticism of those who do things the wrong way.  In describing one graph published in American Education magazine - a confusing 3D graph that shows only 5 pieces of data and uses 5 different colors that in no way relate to that data - he writes "This may well be the worst graphic ever to find its way into print."

This is an excellent book for anyone who needs to present data to an audience.  Business analysts, managers and software developers can all increase their effectiveness by implementing Tufte’s ideas.

Links:
EdwardTufte.com
This book on Amazon