The Success of Open Source, by Steven Weber

Parts of this book are interesting and engaging, and parts are mind-numbingly boring. The author is a professor at Berkeley and his scholarly background shows through strongly. The history of open source software is fascinating, and Weber does an excellent job of walking the reader through its genesis at AT&T Bell Labs to the widespread acceptance found today. His description of open source as "an odd mix of overblown hype and profound innovation" is spot-on, and his comparison of open source to religion was insightful—anyone can read the Holy Bible without a "license" from a Christian sect. The description of the constantly evolving social dynamics of open source is similarly compelling. Where the book drags interminably is during the discussions of the economic and political bases of the movement. Sadly, these last discussions are interspersed through all the interesting parts, making me almost afraid of turning each page for fear of encountering a discourse on tracking "the institutional isomorphism literature by encouraging hierarchical governments to remake their security organizations as networks to interface successfully with their networked adversaries." Well worth your time for the history and underpinnings of open source, but unless you are a political scientist or economist be prepared for a bit of a slog.

First Sentence:

This is a book about property and how it underpins the social organization of cooperation and production in a digital era.

The Secret War Between Downloading and Uploading, by Peter Lunenfeld

This is a frighteningly bad and terribly inconsistent book. Lunenfeld’s point that the computer is dangerously close to replacing television as society’s idiot box is well taken, but his belief that a solution entails people creating as much content as they consume is ludicrous. “...the goal must be to establish a balance between consumption and production, and using the networked computer as a patio-potato enabler, download-only device, or even download-mainly device is a wasted opportunity of historic proportions.” Either he hasn’t seen what passes for content on YouTube these days or his wish is coming true in a wickedly ironic manner. Later he compares the Great Wall of China and the Greek myths to Wikipedia and Linux because they were all built with a communal effort. I wonder if the prisoners and soldiers that built the Wall often got into arguments over which brick went where?

While one one hand he demands people create and upload content, Lunenfeld is on the other offended at copyright laws and authors rights: “By holding on to Mickey [Mouse] ... [Disney] keeps the rest of us out of the storehouse of mutable materials for the creation of new, noncorporate culture.” He certainly didn’t give his book away for free without license. I imagine that M.I.T. (the book’s copyright holder) would frown on that as much as Disney would at someone posting Mickey porn on the Internet.

The author also bemoans the vanishing art of pen-on-paper illustration, calling it the “font of imagination.” He does go on to express hope that photo-realistic computer graphic special effects can be the new source of creative fantasy for the next generation. Sadly, the cover he chose for this book looks like a bad wipe from a 70’s TV show; a lost opportunity to encourage his dream. (While grumbling about the cover I might as well lodge another complaint about the dress: the book is printed almost entirely in boldface; only the sidebars are in a normal weight which makes them very welcome.)

I believe this statement summarizes everything I disliked about this book: “The computer allows the human creative spirit even more flexibility and greater potential than the printing press because it synthesizes so many other media forms.” On the surface this is a thoughtful sentence that draws an astute comparison. A deeper look causes you to realize the printing press didn’t nurture the human creative spirit at all, though, it simply made sharing and preserving content easier. The quiet pride we feel when viewing Rockwell’s Four Freedoms and the tears we shed hearing Elgar’s Nimrod movement in Enigma Variations, the wonder we find in Verne’s words and the rapture spawned by Astaire’s dance, the ingenuity of those that invented the printing press and computer, the love of our family and our quest for wisdom; these things feed our human spirit, not the machines themselves.

First Sentence:

First, we must define the terms of the struggle.

The Back of the Napkin, by Dan Roam

I first came across a pre-programmed whiteboard process as a tool at Borland; the sales department there had a start-to-finish agenda that took a customer through the value proposition of the product line. While the tools weren’t great, the pitch itself was very effective. The Back of the Napkin shows not only how effective visual storytelling can be, but describes a framework for creating your own show-and-tell projects.

The basic tenet of the book is that any problem can be made clearer with a picture. “The real goal of visual thinking is to make the complex understandable by making it visible—not by making it simple.” Roam then proceeds to prove his thesis, demonstrate how to distill ideas into a simple set of pictures, show how different types of pictures are effective for different types of questions, and how to bring it all together into an effective persuasive pitch. Early on there is a short quiz to help determine if you are already a visual person or not (I’m in the middle) and then suggestions about in what order to read the book accordingly. “If you’re a Red Pen person (not visual) and not convinced of the analytic power of pictures, you might want to start with part III )The Visual Thinking MBA) in order to see pictures at work in solving a business problem. If you’re a Yellow Pen person...” I quite liked this as it recognizes that different people learn in different ways, which also happens to echo the lessons in creating a visual framework as well.

The most valuable lesson for me was discovering the template for focusing an idea: SQVID. SQVID stands for Simple, Quality, Vision, Individual attributes, and Delta (change). Dividing a problem into these areas and creating a simple set of sketches for each category helps “force your mind’s eye to look at your idea from many sides in a structured and repeatable way.” I’ve used this a few times since finding this book and it is extremely useful. This idea of forced focus reminds me a lot of Edward de Bono’s Six Thinking Hats, a technique I use in many agile retrospectives, which is probably why it resonated so strongly.

Simple to follow and easy to read, The Back of the Napkin is an effective book that does an excellent job not only explaining why visual thinking is so powerful, but how it can be used in everyday life.

First Sentence:

What’s the most daunting business problem you can picture?

The Art of Community, by Jono Bacon

During my recent job search, one of the positions for which I interviewed was an Agile Community Leader. I firmly believe that agile techniques give us the best path to developing quality software, so when this opportunity came along I was very interested. My professional career has been all about building software, so moving to a community leadership position provided something entirely different and I wasn’t exactly sure what to expect. I met with a friend that was already in the community business and among other things he recommended The Art of Community. Great advice; even though I ended up not getting the job, I thoroughly enjoyed this book.

The author, Jono Bacon, is a longtime open source advocate and the current Ubuntu community manager. He put together this excellent discussion on not only how to go about building and maintaining a collaborative organization, but how to keep it fresh and fun at the same time. A lot of what Bacon believes hit close to home with me; what it takes to make a community work sounds quite similar to what makes agile work. Defined milestones in a community are similar to an agile release plan. Milestones are reached by defining smaller objectives each with success criteria and an implementation plan, analogous to stories, acceptance criteria, and tasks. And in both arenas regular reflection to enact changes in process and tools are considered critical. Seeing as how in agile building teams is just as important as building software I guess this shouldn’t be that surprising, but I am continually pleased to find new ways of applying trusted techniques in new ways and in different domains.

One sentence that stuck with me was about honesty: “If your product sucks, you don’t cover it up but instead try to fix it.” This sort of transparency is exactly how I think we should approach most things, but is sadly rare. And not only in software development and community building; imagine if politicians tried harder to solve the countries problems instead of simply getting reelected! Another bit I liked was a great idea for brainstorming: figure out how to make things suck instead of making them great. Not only is this a fun ice breaker, it really gets people talking. After collecting approaches, examine the inverse of the terrible ideas for some truly interesting approaches! I look forward to trying this out sometime soon. Useful, funny, and informative, I enjoyed every page of this book.

First Sentence:

As my watch ticked over to 6 p.m., I knew I was in trouble.

Emergence, by Steven Johnson

Distributed systems combine the output of multiple processes to solve a single problem, a common topic in computer science. Johnson explains this subject in simple terms, starting with the common ant. An individual ant does not have a view of the “big picture;” it just follows certain simple rules that trigger when certain simple phenomena are encountered. However, the colony as a whole can obviously manage its society, creating complicated and advanced anthills and balancing the various roles (worker, soldier, ...) needed at any given time. The queen, contrary to popular belief, is not the central architect; actually, the colony as a whole makes decisions in a distributed fashion based on incomplete—or emerging—data points.

As other authors have noted, making decisions in this fashion is something at which humans aren’t very skilled. Because the volume of data that is available to us at this point in history, the implication is we too often become paralyzed when trying to make decisions. Interestingly, Johnson posits that our children will be much better at this than we are. Younger generations are more comfortable with less control of their world, largely because of video games. Titles like The Legend of Zelda don’t have a set rulebook, so players become skilled at guessing causal relationships and building and testing working hypotheses of the true underlying rules. This skill translates to being “more tolerant of being out of control, more tolerant of that exploratory phase where the rules don’t all make sense, and where few goals have been clearly defined.”

Johnson’s style is smooth and easy, with a dose of levity for color. “If people were somehow deprived of the theatrical conflicts of city sidewalks, they’d all end up hollow men—or worse, Republicans.” Ha. Clear and clever writing makes a complex topic feel accessible, and the time to pass quickly.

From ants to urban planning to memes, the author covers a lot of ground about emerging systems, and hints at the importance of this subject in our near future. With Facebook, Twitter, and Foursquare just in the social networking arena, new ways of processing data are going to be needed. The sheer volume of information is going to require that decisions are made based on localized or incomplete sets. Emergence is an intriguing glimpse into possible methods that may be used to accomplish this.

First Sentence:

It’s early fall in Palo Alto, and Deborah Gordon and I are sitting in her office in Stanford’s Gilbert Biological Sciences building, where she spends three-quarters of the year studying behavioral ecology.

The Five Dysfunctions of a Team, by Patrick Lencioni

This is a fast read—about 200 pages but a small size, large font, and vacuous phrasing. The simplicity is a good indication of the ideas contained within however; Lencioni’s approach to what makes an effective team is remarkably simple too. In order, a team needs trust, healthy debate, commitment, accountability, and rewarding results. You can’t skip any of these phases along the way; e.g., without trust it isn’t possible to have unfiltered discussions. Simple and obvious, like many of the popular business theories today. Unlike some popular theories though, these have the ring of truth.

This is a fable book, like The Goal or Virtual Leadership. The story in Five Dysfunctions was clumsy and contrived, but the points it tries to make come across well. It was hard to see how some of these techniques would work in the real world where people have multiple motivations and are more complex than cartoon characters, but the assessment template and discussions that close the book seem very useful. Despite the mixed review this is well worth your time, but make sure this isn’t the only book you take on an airplane!

First Sentence:

DecisionTech was located in Half Moon Bay, a foggy, coastal farming town just over the hills from San Francisco Bay.

Crystal Clear, by Alistair Cockburn

Crystal Clear is another one of the many agile management styles out there today. It is geared specifically for small collocated teams not working on life-critical systems. The wildly different chapter formats I found odd, but Cockburn explains it well: “It is not my ambition that every reader should like every chapter and format. Rather, my hope is that through the use of different perspectives, each reader, coming from his particular background, can find some chapter format that conveys what is needed in order to understand Crystal Clear’s main ideas.” A lot of the methodology doesn’t apply to my current situation (Crystal Clear demands collocation but my team is scattered all over North America) but I still found some interesting ideas here. One I particularly liked was that Crystal allows for teams to choose less-than-optional ways of working; as long as the team is delivering software successfully all is well. This is much more forgiving than many methodologies which seem to require striving for perfection. Another concept I like is the approach to risk: “A safe methodology is one that increases the likelihood of the project succeeding.” Most risk discussions revolve around what can go wrong; this spin of increasing success factors rather than reducing avenues of failure I find to be much more positive. Because of the focus on small teams this isn’t directly applicable to all groups, but everyone should be able to glean something useful from this book.

First Sentence:

I distilled Crystal Clear by asking successful small teams what they would keep or change in the ways they worked.

User Stories Applied: For Agile Software Development, by Mike Cohn

Every agile team is different. Team dynamics and synergy are key to a truly self-directed team, so every unique group of individuals will have to discover what works for them and what doesn’t. One thing on which most teams (regardless of how different they appear or behave) will agree, though, is that writing software specifications is hard. English is a notoriously imprecise language, and computers are meticulous to a fault; this combination is what makes requirements so difficult. The use of user stories and agile to combat this hardship is very effective, and Cohn does an excellent job of explaining these concepts.

The main idea behind user stories lies in the idea that a story represents a requirement, it doesn’t document it. The goal of a story is to encourage communication about what a feature is and how it should behave, not a treatise on the behavior that can be thrown over a wall to development. In the traditional software world, management will create a Product Marketing Document to define how they want every last feature to behave. Engineering will respond with a Functional Specification, which is a rewrite of the first document with a slightly different point of view. Development is then expected to go off for a year or so and create the product. Simple, right? Cohn discusses this approach, and sums it up with one of my favorite passages in the book: “Most of the times when I see two groups writing separate versions of essentially the same document I already know they are positioning themselves for the end-of-project blame sessions and for claiming to know the intent of the document. This type of silliness goes away with user stories. Along with the shift to conversations from documentation comes the freedom of knowing that nothing is final.” The phrase “nothing is final” frightens many executives with whom I’ve worked, but when you consider that all significant projects undergo changes during development (have you ever had a released application that exactly matched the original specification?) it really isn’t any different than reality, it just recognizes that change is inevitable and accounts for it.

Even if you are familiar with agile and user stories, this book is a great read. It is filled with examples both positive and negative and does an excellent job explaining not only what user stories are, but what they aren’t as well. These negative explanations in particular are quite valuable, as they compare and contrast many popular requirement gathering techniques such as Use Cases and IEEE 830. Looking at how these other approaches work helps clarify what the scope of user stories are supposed to be. I highly recommend this to agile teams, especially product managers and ScrumMasters.

First Sentence:

Software requirements is a communication problem.

Collaboration Explained, by Jean Tabaka

Collaboration Explained is a great book that works on two levels: both a treatise on a topic and an ongoing reference after the initial study. While there is a lot of good information about popular agile methodologies and fostering collaboration, where it really shines is on the topics of meeting facilitation. My favorite anecdote told of a company that had sign above each meeting room door: “If you have not received a purpose and agenda for this meeting, please turn around and return to your desk.” I sure wish I could work at a place like that!

At the heart of the book is the idea that collaboration is powerful. Tabaka mentions many familiar names that believe in this credo of “People over process” but somehow omits Michael Coté who named his blog with this phrase! She points out that with all the differences in the various popular agile techniques, collaboration is the “daily glue that agile teams apply in order to accomplish their joint undertakings.” As someone that follows general agile techniques but doesn’t subscribe to any particular methodology this rings especially true.

One of the collaborative tools that Tabaka discusses is the “fist of five.” This is a way of quickly gathering a feel for where the group stands on a particular issue with more granularity than a simple pass/fail vote. The idea is that you ask for a showing of the fist of five (I call this the “fiery fist of death” because I like to inject humor wherever I can—and I can never remember the “proper” name!) when you want to get a feeling for where the group stands on a particular decision/solution. Everyone then simultaneously holds up a hand extending fingers indicating their position:

1. Five fingers: this is exactly what we should do and we are geniuses for thinking of it.
2. Four fingers: a solid plan that I’m happy to implement.
3. Three fingers: I can live with and support this decision.
4. Two fingers: I have a problem with where we are and we need to keep discussing.
5. One finger: use any finger you’d like to express your feelings.

Of course, Tabaka doesn’t express the fingers in quite this way but the end result is the same. This is a powerful technique that I’ve found quite useful, especially in groups that like to hear themselves talk. When I think that we are starting to cycle in our discussions calling for the fist goes a long way towards ending deliberation and moving the group forward.

As I said earlier, this is a great book not only for the discussions but as an ongoing resource. Section IV is particularly valuable, containing templates for many different types of meetings commonly encountered during agile development. Any team leader can learn a lot from reading this book, and individual contributors will benefit by getting a better insight into what makes a group truly collaborative.

First Sentence:

With the current interest in adaptive, more reliable software development practices, project teams and their managers are taking a renewed look at the many people aspects that either contribute to or detract from project success.

Agile and Iterative Development, by Craig Larman

This is one of those books that is useful as both an ongoing reference and as an introductory text. It provides not only a walk through of several iterative software development techniques, but targeted resources for further reading at the end of each chapter and a FAQ and bibliography at the close of the book. The topics are presented in a narrative fashion with many illustrative examples, making for both easy reading and high retention; knowing Larman’s history of developing and presenting training courses this is no surprise. Much like Rothman’s Manage It!, one of the great things about this book is that it delves into things needed for success outside the development methodology at hand; for instance, wikis and mind-maps get mentions here even though they aren’t specific to any particular technique. Larman also does a good job of discussing both the positives and negatives of various approaches, where many competing books tend to avoid the trouble areas and stick to the party line. This holistic view of the world is what makes this text rise above its brethren.

Another reason I enjoyed this book is my connection with the author: we used to work together a decade or so ago at ObjectSpace. In fact, I was one of the guys that interviewed Craig before he joined. At the time I was working in C++ and Craig had mentioned that he had a brief acquaintance with the language. He was being considered for creating and teaching OOAD and Smalltalk courses as I recall, but as an excuse for Craig to meet more people in the company we were asked to get together. Craig had flown in from Canada for a day of interviews and the word in the halls was all positive going into our session. After introductions I started in on the standard C++ language questions and we quickly discovered that he was exactly accurate with his self-evaluation of “vague familiarity.” As the session petered to an awkward close, Craig suddenly perked up and reached into his bag, pulling out a small bottle (think hotel liquor sized) of Canadian syrup saying, “I brought this for you!” Turns out he brought syrup for everyone, but the timing of remembering a gift at the end of a clumsy discussion was priceless. Of course he was hired and went on to great things, but that remains one of my favorite interview stories.

First Sentence:

What value will you get from studying this book, an introduction to iterative and agile methods?

Servant Leadership, by Robert K. Greenleaf

This book was written thirty years ago, but is still very relevant today. Not just in its message that true leadership is an inner quality as much as an exercise in power, but in the world that prompted the author to put pen to paper. “We are prone to adventurous and illegal wars. Confidence in the integrity of elected officials is at a low point. The total tax structure is a perversion. The treatment of prisoners is barbaric. The cost of it all is staggering.” Sound familiar?

Servant leadership embraces the idea that leaders should serve others by removing obstacles and staying focused on the organization’s values and integrity rather than any overt decisions. I find this idea appealing as it fits in well with agile software development techniques. An agile leader is responsible for having the big picture and for removing any roadblocks the team encounters, but not responsible for doing any of the work itself. This is very much the focus of the book.

While the themes were both interesting and valuable, the style was off-putting. I got the strong impression that the author was a bit of a hippie; not a hipster, but a tie-dyed hippie. I’m all for the zen aspects, but the anti-establishment ideas were often just silly. The nuttiest was the thought that we should reform our educational system by only teaching those that actually want to be taught. While it is a lovely idea that children will attend school without coercion and once there pursue a course of well-rounded instruction, anyone that believes this will lead to a scholarship intensive society is smoking something. Of course, hippies and smoking aren’t exactly enemies...

First Sentence:

Servant and leader—can these two roles be fused in one real person, in all levels of status or calling?

Manage It! Your Guide to Modern, Pragmatic Project Management, by Johanna Rothman

This book is best summed up on the cover: “There is no One True Way that works for all projects.” That message alone makes this one of the most valuable management texts I’ve read in a while. Most books in this genre detail a single approach to project management and claim superiority over all others. Rothman take a much more pragmatic approach (not too surprising as this is published under The Pragmatic Programmer banner) that is refreshing in its honesty. Instead of being told to drink the kool-aid for any one particular style, we are shown the buffet and told to take what we want.

There are many gems of wisdom here, several of which resonated with me. The variety of topics is wide, ranging from planning to completion, managing up as well as down, hardware projects (albeit briefly) as well as software, and managing multi-site projects and multi-project programs. The topic of testing has a good overview as well, from unit level at one end of the spectrum to system testing at the other. One interesting discussion describes the difference between QA and testing (and today’s reality that most QA groups are really testing groups): QA can and should reach into all aspects of a product—including the development process itself—and has the power to make changes to improve the quality of not just the product but the organization as a whole. I’ve met a few QA managers that fit this description, but by and large I realize my experience has been with mis-titled testers instead; I suspect this section will color my view towards this area of software development for the foreseeable future.

One piece of advice I liked was the recommendation for managers to develop multiple skills while on a project: interpersonal, functional, domain, and non-technical. Instead of simply getting to know the requirements and schedules, work with everyone involved to become a well-rounded manager in both knowledge and skill. Even if the project fails (and Rothman also advocates that knowing when it is time to leave a failing company or project is an important skill) your professional development still advances. Too often it is too easy for me to get caught up in the day-to-day demands of getting a project to completion; remembering to stop and smell the flowers and examine the big picture strikes me as an excellent idea.

This book covers a wealth of topics and yet is less than 350 pages; this means that many terms and approaches aren’t covered in great detail. They are all summarized, though, and a healthy bibliography is in the back so avenues of further research are easily discovered. If you are about to embark on your first management gig or if you are a grizzled veteran, this text should be on your bookshelf.

First Sentence:

The easiest way to start a project wrong is to just start.

Leading Geeks, by Paul Glen

This book echoes a lot of beliefs that I hold true, and validation is always a pleasant thing. You’d think I liked it because of that, but I found it a tough read. The style is very dry and overly structured: the premise is broken into a few large sections, each section split into main topics, each topic contains a list of items, each item detailed. While functional decomposition is great for software, it makes for a tedious book! Plus, when an item touches on something covered elsewhere, a simple “Chapter Ten will discuss this” is written and tying the points together is an exercise left for the reader. In a few places this would happen multiple times on the same page, a habit I found really irritating.

That said, the basic theme is one with which I wholeheartedly agree: successfully managing software developers is much more complicated than simply handing out requirements and posting deadlines. A leader of technical people needs to provide a comfortable environment where people can be creative and productive. Insulating the talent from corporate politics while singing their praises up the chain and managing the ambiguity that is inherent with software are other major facets. Finally, something that good leaders understand is geeks don’t suffer fools gladly; amusingly this is often directed at the leaders themselves!

A hodgepodge of other facets this book discusses: power is useless for manipulating geeks; creativity can’t be controlled; and dates not tied to anything in reality will never motivate a team. All of these I believe are closer to the truth than not, but I wouldn’t call them infallible, either. For instance, while developers tend to respect knowledge over power, we’ve all been through enough layoffs to understand who really holds the cards. Interesting discussions.

While Glen mostly gets it, he has some odd opinions on seating. He feels that team rooms are bad for concentration and lead to productivity loss. Cubes, though, can be a good thing if they are all the same because there isn’t any status attached to having an office. I think that the team should be able to make this sort of call; some groups I’ve seen strongly prefer a bullpen and it clearly helps the project to have them all together. Others want offices and a conference room for group meetings. Nobody wants cubes—nobody. Cubes are the worst of both worlds: they give the illusion of privacy without actually granting any, yet replaces natural collaboration with prairie dogging. Of course, I’m currently stuck and miserable in cubeville right now so maybe this passage simply rubbed me the wrong way.

I think if you are a non-technical person that finds yourself in charge of a software team, this book can provide some solid insight into the world of developers. Individual contributors that are promoted to managers could benefit from reading this too; hopefully they will pick something up about how different leading is from doing. Experienced supervisors, though, might be a bit bored.

First Sentence:

I hope that you have begun this book with a head full of questions:

• What’s different about leading geeks from leading anyone else?
• What can I do to better leverage my organization’s investment in these expensive, valuable, and temperamental employees?
• What makes geeks so different to manage?

Virtual Leadership, by Jaclyn Kostner, Ph.D.

I don’t quite know what to think of this book. There were some good lessons about leading graphically disperse teams, but the story framed around the lessons is pretty silly. A man finds a magic coin that lets him discuss the challenges of long-distance management with King Arthur. That’s right, King Arthur. While a fictional story chosen to illustrate principles can work, this one was so silly it was hard to take seriously. The idea is that the Knights of the Round Table were scattered all over England yet King Arthur forged them into a group that was so effective their legend is still talked about today—clearly Arthur knows a thing or two about virtual management.

Ridiculous story aside, there are some good points in here. One of the main reasons I think agile development is so effective is because it places a high value on collaboration. While agile can work in a distributed environment, it is certainly more difficult. I’ve run teams that were scattered across several cities, and it isn’t much fun. What seems to naturally happen is that the various localized groups form cliques, and the cliques tend to resent each other. Okay, resent may be a strong word, but phrases like those guys said... and Houston wants to know... start to creep into the common vernacular. The limited interaction and limited knowledge of the individual groups naturally causes a dearth of trust. Trust, clear communication, and focus are essential; this book illustrates some good ideas for turning a splintered organization into an effective one.

First Sentence:

“No one’s ever going to believe me,” Jim Smith thought to himself.

Envisioning Information, by Edward R. Tufte

I can’t decide if I like Tufte’s work or not. The ideas presented are thought provoking and the images capture your attention like few works I’ve ever seen; however, the attitude that comes through his writing reminds me of the worst of my college professors. I suppose in the idea of not shooting the messenger I should give him a pass because the message itself is strong. This book talks about how to best display information, especially lots of information in a small amount of space. I personally find cartography fascinating and there are plenty of maps to be found here. Color is another topic that is covered but could use an update in my opinion; in our new supposedly accessible world Section 508 is becoming more important but ignored in this text. Like Tufte’s other works I’d recommend this one, for the pictures if nothing else. Visually amazing.

First Sentence:

Even though we navigate daily through a perceptual world of three spatial dimensions and reason occasionally about higher dimensional arenas with mathematical ease, the world portrayed on our information displays is caught up in the two-dimensionality of the endless flatlands of paper and video screen.