Miscellaneous Books

This article appears in slightly different form in the September/October 2006 issue of IEEE Micro © 2006 IEEE.

I have covered many subjects in this column, but the majority of my reviews are of books in the fields of computer science, software, project management, and technical publication. In the last few months I have seen a large number of new works. Their subjects are interesting, and their production values make them a joy to look at and to hold.

Rather than choosing just a few from among these books, I present a larger than usual selection -- though there are many more books I wish I had time and space to review. Many of these books are from a few small publishers. I'll let you draw your own conclusions about why that is.

Interface Oriented Design by Ken Pugh (Pragmatic Bookshelf, Raleigh NC, 2006, 232pp, ISBN 0-9766940-5-0, www.pragmaticprogrammer.com, $29.95)

Ken Pugh is an experienced software developer and an award winning author. In this book he treats an important design subject that many developers, even experienced ones, fail to appreciate. 

Every introduction to object oriented programming begins by explaining the key concepts of encapsulation, polymorphism, and inheritance. Pugh shows how to use interfaces to achieve true encapsulation and polymorphism. He explores the problems that inheritance presents and shows how interfaces can sometimes provide a better alternative to inheritance.

In his book Object Oriented Software Construction (Prentice Hall, 1997), Bertrand Meyer formalized the idea of design by contract. An interface is a contract that provides explicit provisions about the preconditions for invoking a method and the conditions that should follow its return. Meyer also specifies certain implicit rules that all contracts should follow. Pugh applies design by contract throughout his book, but he focuses on only the main points, which he simplifies, in an homage to Isaac Asimov's I, Robot (Gnome, 1950), as the three laws of interfaces:

1. An interface's implementation will do what its methods say it does.
2. An interface implementation shall do no harm.
3. If an implementation is unable to perform its responsibilities, it shall notify its caller.

Interface design is not an exact science. There are many ways to achieve the same basic functionality. Meyers discusses the issues and considerations that will help you make optimal designs. Many of these, like loose coupling, are fundamental design principles. Others are specific to designing interfaces. Meyers illustrates his principles with several case studies, then looks back to summarize the patterns that they illustrate.

The chapter that I found most helpful is the one on interfaces and inheritance. Inheritance is a powerful means of developing a hierarchy of behaviors and implementations. But a hierarchy of behaviors can be inflexible and limiting. Interfaces focus on behaviors that may or may not be hierarchical. A hierarchy of implementations centralizes the code for common behaviors, but the delegation pattern can provide a way to achieve the same end for non-hierarchical interfaces.

This book will repay careful study. If you design computer programs, especially in object oriented languages, you should read it. 

Ajax Design Patterns -- Creating Web 2.0 Sites with Programming and Usability Patterns by Michael Mahemoff (O'Reilly, Sebastopol CA, 2006, 654pp, ISBN 0-596-10180-5, www.oreilly.com, $44.99)

Michael Mahemoff is a computer consultant whose academic research dealt with reusing designs in software and in user interfaces. Ajax (loosely an acronym for asynchronous JavaScript and XML) is a design pattern first described early in 2005 by Jesse-James Garrett. It enables web applications (for example, Google Maps) to provide highly interactive user interfaces within browsers, without using plugins.

Ajax is not a new technology. It is simply a new way of using old technologies to design applications that run in browsers and interact with remote servers. Mahemoff has compiled and described the patterns and best practices that have grown up around this new approach. Any web application designer can benefit from reading his book.

Documenting APIs -- Writing Developer Documentation for Java APIs and SDKs by James F. Bisso and Victoria Maki (Bitzone, Richmond CA, 2006, 318pp, ISBN 0-9630021-0-4, www.bitzone.com, $49.95)

I have known and worked with the authors of this book for many years. Jim Bisso is a software engineer at Sun. Viki Maki is a technical writer and trainer. Both have taught classes in technical documentation. 

The authors take you through all aspects of documenting Java APIs (application programming interfaces). They explain the different roles of different kinds of API documentation. For example, a programmer's guide and an API reference serve different purposes and complement each other.   

Though the authors focus on Java, much in the book applies to API programming for other languages. Buying the book entitles you to access additional information from an associated website, which contains sample projects that the book refers to. 

The authors write from the viewpoint of the person documenting the interfaces, but developers can get valuable insights from understanding that viewpoint. In many cases, developers provide the bulk of API documentation.

My connection with the authors makes me a biased reviewer, so I am hesitant to say too much about the book. I think I am safe, however, in saying that this is the only book on this subject. If you are involved in API documentation, you should definitely read it.

Communicating Design -- Developing Web Site Documentation for Design and Planning by Daniel M Brown (New Riders, Berkeley CA, 2006, 368pp, ISBN 0-321-39235-3, www.newriders.com, $39.99)

Dan Brown is a web consultant who specializes in information architecture and user experience. He has written an unusual and valuable book. It is not about the mechanics of designing and implementing websites. Rather, it describes the artifacts that support clear communication among the designers and between the designers and their clients. Wireframes, site maps, flow charts, content inventories, personas, and other artifacts (known collectively as "the deliverables") provide the basis for this communication. 

The deliverables are independent of the design and development methodologies you choose to use. Using definitions, explanations, and clear pictures and diagrams, Brown shows how to produce and use these artifacts. If you are buying or selling websites, you should read this book.

CSS -- The Missing Manual by David Sawyer McFarland (Pogue, Sebastopol CA, 2006, 494pp, ISBN-13 978-0-596-52687-0, www.missingmanuals.com, $34.99)

David Sawyer McFarland is an author, a teacher, and a webmaster. He has designed many websites. Cascading style sheets (CSS) is a language that enables web designers to apply global styles to the raw HTML they use to encode the content of web pages.

When browsers and websites first became popular in the early 1990s, designers were forced to apply font size, color, and other elements of appearance directly to each HTML element (heading, paragraph, and so forth) that they created. There was no mechanism to ensure that every first level heading on a given page, let alone on the whole website, had the same appearance. Furthermore, HTML has only a limited number of ways to control appearance. Sophisticated visual designs required cumbersome misuse of HTML elements (for example, tables).

Designers soon recognized these defects, and CSS was born. But HTML was evolving rapidly, and CSS had a late start. It was not until recently that we had a version of CSS that designers could use effectively with their designs.

Using CSS is relatively simple, but it requires looking at design in a different way. McFarland explains this viewpoint, then goes on to show how to use each feature of CSS. He also starts with common design problems (for example, styling tables or forms) and shows how to use CSS to solve them.

The Missing Manual series of books fills the need for user centered documentation for many underdocumented products. This book does the same for CSS. 

Secrets of RSS by Steven Holzner (Peachpit, Berkeley CA, 2006, 344pp, ISBN 0-321-42622-3, www.peachpit.com, $24.99)

Steve Holzner is a prolific author of books about XML and related topics. RSS (really simple syndication) is, as the name suggests, a system for syndicating content. That is, it enables publishers to make content available in an XML format called an RSS feed. It enables subscribers to aggregate content into personal collections and read that content using a browser. Many web logs use RSS feeds to distribute content.

Following the excellent style of many books from this publisher, Holzner provides profusely illustrated step by step instructions for producing and consuming RSS feeds.

If your only interest in RSS is to be a subscriber, this book is more than you need. If you wish to publish, however, this book provides a clear view of everything you need to do.  

.NET Internationalization -- The Developer's Guide to Building Global Windows and Web Applications by Guy Smith-Ferrier (Addison-Wesley, Boston MA, 2007, 670pp, ISBN 0-321-34138-4, www.awprofessional.com, $49.99)

Internationalization is the process of preparing software to be easily translated (localized) for users who expect different languages, date formats, and other cultural conventions.

 

Guy Smith-Ferrier is a developer who specializes in internationalization. His book focuses on how to internationalize Windows Forms, ASP.NET applications, and other programs running in the .NET environment. 

Internationalization is not conceptually difficult, but it requires building and using a large and complex infrastructure. Fortunately for .NET developers, .NET includes such an infrastructure, so you don't have to build your own. This book teaches you how to use that infrastructure. If you develop applications in a .NET environment, you will sooner or later need to understand how it supports internationalization. This book is the place to start.

Weinberg on Writing, Knuth, Java to Ruby, DITA Intro

This article appears in slightly different form in the July/August 2006 issue of IEEE Micro © 2006 IEEE.

This article looks at old masters and new challengers.

Words from the Masters

In this section I look at works by two of the most respected and most prolific writers in the field of computer programming and beyond.

Weinberg on Writing -- The Fieldstone Method by Gerald M. Weinberg (Dorset House, New York NY, 2006, 208pp, ISBN 0-932633-65-X, www.dorsethouse.com, $24.95)

Gerald Weinberg has 40 published books to his credit, so I was eager to read about the techniques that work for him and have worked for many participants of his writing workshops. He describes his approach to writing as the fieldstone method. It derives from the first lesson he learned in college: only write about things you care about. As a result, he goes through life noticing what he cares about and making notes. These unordered notes are like the fieldstones you might collect to make a stone wall. He goes to great lengths to ensure that he can find these notes when he needs them. Then, when he decides that he wants to write about something, he gathers appropriate fieldstones and builds a book or essay the way a skilled stonemason would build a wall.

Building a wall requires you to select the right stones, organize them, and then assemble the wall -- trimming and polishing to make the best wall you can with what you have. Writing by the fieldstone method requires the analogous actions. Weinberg has developed principles and procedures for all of those actions. He describes them in this book, using frequent anecdotes and many exercises. These slow you down and keep you from skimming -- like the chunks of celery that make you chew your potato salad thoroughly.

Weinberg shows how his methods prevent writer's block, the paralyzing affliction that can lead writers into addictive behaviors that keep them from working for weeks at a time. He regards writer's block not as a disorder in you, the writer, but as a defect in your methods. It is natural to have too few or too many ideas. The problem comes from what you do about it. Weinberg tells you to ask yourself the Goldilocks question: is the number of ideas I have to work with too many, too few, or just right? Depending on the answer, you gather more ideas, dump some, or start trimming and polishing the ones you have.

Weinberg mixes his practical techniques with what we referred to as "new age" in the 1970s. One of his students writes that Weinberg offers intangibles like "motivating, raising self-esteem, building confidence in writing, considering self-other context, teaching the true meaning of discipline, thinking more clearly, and raising awareness." I'm sure this comes across more powerfully in his workshops, but it is amazing how much those intangibles come through in this short book.

Weinberg addresses the mechanics of selecting, organizing, trimming and polishing. Here he gives excellent advice, including some practical techniques for achieving the famous dictum of Strunk and White: omit needless words.

Weinberg addresses the difficult problem of knowing when to stop. The fieldstone method makes this easier than other approaches do. For example, if you start by developing an outline, you may be held up by even a minor point that you may not be able to provide right away. He likens it to waiting for the number that completes your card in a game of bingo. I thought of that analogy as I read Donald Knuth's latest contribution to his magnum opus, The Art of Computer Programming. 

Other authors are stopped by their desire for perfection or their fear of criticism. All of these seem silly in the context of building a fieldstone wall.

Weinberg provides useful anecdotes about his own experiences with publishers. The Psychology of Computer Programming was not his first book, but it was his first blockbuster. Aspiring writers may find it encouraging that Weinberg had difficulty finding a publisher who would take it. He persisted, and finally found a publisher. When I reread parts of that book recently, I remembered how radical they seemed in 1971. As I look around at today's programmers, I see that their underlying ethic and approach contain much that came from that book  -- even though few programmers have ever heard of it.

This summary is no substitute for reading the book. I have left out many good parts that are hard to summarize. For example, I'd like to steal the entire chapter on plagiarism. If you want or need to write, this book can help. It is full of practical advice that can help you succeed.

The Art of Computer Programming, Vol. 4, Fascicle 4 by Donald Knuth (Addison-Wesley, Reading MA, 2006, 128pp, ISBN 0-321-33570-8, www.awprofessional.com, $19.99)

Don Knuth received the ACM Turing award in 1974, became a Fellow of the British Computer society in 1980, was a charter recipient of the IEEE Computer Pioneer award in 1982, and received the J.D. Warnier prize for software methodology in 1989. He holds the unique title of emeritus professor of the art of computer programming at Stanford University.

When I reviewed the second edition of volume 3 of The Art of Computer Programming (Micro Review, Sept/Oct 1997), I compared the entire work to Herman Melville's Moby Dick. I did not mean that it constitutes an obsession on Knuth's part. Rather, it is, as Moby Dick is to students of literature, a work that you should study when you begin your career and reread as the years go by. Unfortunately, this is only partially possible. Though Knuth announced six volumes in 1969, he has to date completed only three, and there is no firm schedule for the rest. In fact, his greatest accomplishment, his single-handed design, programming, and documentation of the TeX system for document preparation, intervened. He spent many years developing that tool and then spent more years using TeX to "reimplement" the first three volumes.

Knuth has now devised a scheme for publishing the remainder of The Art of Computer Programming a little more quickly. Inspired by Charles Dickens, a nineteenth century English author who published novels in serial form, Knuth has begun to publish volume 4 in parts, or fascicles. In the last year he has brought out 4 such installments. The first fascicle, long-time Knuth fans will be delighted to hear, describes MMIX, an imaginary computer to replace the thirty-five year old MIX, the imaginary computer he used to describe algorithms in his original work. While MIX represented an idealized mixture of the assembly languages of 1960s era computers, MMIX is "A RISC Computer for the New Millennium."

Volume 4, as originally announced in 1969, covers combinatorial algorithms. Fascicles 2 and 3 deal with generating tuples, permutations, combinations, and partitions. These lead up to fascicle 4, which deals with generating trees. This fascicle also reviews the history of generating combinatorial patterns. For example, King Wen devised the I Ching in 1143 BC, and it is still a bestseller today. It has 64 chapters, corresponding to 64 hexagrams in which each of the six lines has one of two values -- yin or yang.

I can't in good conscience urge you to rush out and buy this book (unless you're a librarian). Aside from designers of searching algorithms, most people will not find it directly relevant to their work. Nonetheless, it is important as part of a coherent encyclopedia of computer science. And there is the added incentive that Knuth will pay you $2.56 for each typo that you find.  

Like the monks moving the Tower of Hanoi, Knuth soldiers on. I hope he lives long and prospers, and I hope he never finishes.

Challengers

Our industry has many stories of challenges to accepted ways of doing things. Some of the challenged leaders lost their positions. Others held on. Here are books about new technologies that challenge accepted leaders.

From Java to Ruby -- Things Every Manager Should Know by Bruce Tate (Pragmatic Bookshelf, Raleigh NC, 2006, 164pp, ISBN 0-9766940-9-3, www.pragmaticprogrammer.com, $29.95)

Bruce Tate is a consultant specializing in persistence and lightweight development in Java and Ruby. He is the author of the award winning Better, Faster, Lighter Java and a number of other books. He wrote this book for managers, or for developers who are advising managers, who are considering moving some development projects from Java to Ruby.

Java has come a long way since its introduction eleven years ago. In the May/June 1996 Micro Review, I described the design processes by which C++ and Java put themselves forth as object-oriented successors to C. I also wrote at the time:

I think Java will eventually replace C, but I think C++ will persist as its competitor for a long time. That conflict will probably follow the model of the RISC vs CISC wars, so that ten years from now it will be hard to know which is which.

Those ten years have gone by, and Java has acquired a lot of the complexity of C++, especially in the competing frameworks that developers must evaluate and learn to use. Meanwhile, a number of more nimble languages have acquired large communities of users. According to Tate, one of those languages, Ruby, in the form of the Ruby on Rails framework, presents a better solution than Java for an important class of problems: database-backed web applications.

Tate makes the point that moving to a new computer language is risky in many ways. You should not consider it unless you see serious problems with your current situation. Tate suggests that you consider Java's greater complexity and lower productivity as risks to be balanced against the risks of moving to Ruby. He sees a large part of Java's complexity as coming from the various frameworks that Java programmers must use. He compares this with the simplicity and productivity of Rails.

Tate presents other arguments and provides greater detail. He doesn't try to decide for you, but if you decide to try Ruby, Tate provides detailed strategies for migrating and for coexisting with Java. Tate acknowledges that not everybody agrees with his point of view. He has a pro-Ruby bias, but he presents the arguments on both sides. He includes the comments of many industry experts, most notably Martin Fowler, who are frustrated with Java's deficiencies. 

If you are seriously considering a change of this sort, you should read Tate's book carefully. 

Introduction to DITA -- A User Guide to the Darwin Information Typing Architecture by Jennifer Linton and Kylene Bruski (Comtech, Denver CO, 2006, 348pp, ISBN 0-9778634-0-9, www.comtech-serv.com, $50.00)

Most software products require some sort of documentation, above and beyond what the bare user interface provides. Providing that documentation has traditionally been the task of technical writers. Those writers produced manuals: printed or online books that covered the subject sequentially. 

Over the last ten to fifteen years, many movements have converged upon a model of documentation that throws away the book. In this model, writers write topics -- atomic pieces of information that they recombine as needed and present to users online on demand. Users press a help button specific to the task they are working on or use indexes, tables of contents, or search engines to find the topics they need. Topics typically describe procedures, but they can also explain concepts or provide reference information.

As this model has developed, writers have tried to achieve its goals by using the available book-oriented tools. In the area of structured writing, this meant using the Docbook system, which was originally developed in the 1980s to work with SGML (Standard General Markup Language, an ancestor of XML). The Docbook DTD (document type definition) is in widespread use with XML publishing tools today.

Darwin Information Typing Architecture (DITA) marks a clean break with the book model. Its designers at IBM started from topics. They introduced a system of maps to take the place of the structure imposed by a book. Maps externalize dependencies and cross references, which facilitates automated recombination and reuse of topics.

Until now, there have been few organized presentations about DITA for writers. Linton and Bruski try to fill that need. They build the book around a complete online help system developed in DITA from the ground up. If you work your way through it, you will learn how all the pieces fit together. 

Unfortunately, the book does show signs of the speed with which it has been brought to market. Its structure is a combination of parts, sections, and lessons, but no chapters. It appears to superimpose a book's outer trappings onto a set of lecture notes and lab instructions. Also, the editing leaves a lot to be desired.

If you are in a hurry to understand DITA, this book can help. If not, you might want to wait for the second edition.

More on Old Topics

This article appears in slightly different form in the May/June 2006 issue of IEEE Micro © 2006 IEEE.

This time I look at interesting books on subjects I have touched on in recent reviews.

Globalization

The books in this section give interesting perspectives on the dark side of globalization.

In Defense of Globalization by Jagdish Bhagwati (Oxford, New York NY, 2005, 320pp, ISBN-13 978-0-19-530003-1, www.oup.com, $15.95)

Jagdish Bhagwati is a Columbia University economist. His 1993 book, India in Transition, detailed problems with the bureaucracy that had grown up in the decades after India's independence from Britain. The reforms that he endorsed in that book have contributed greatly to India's rapid economic advance in recent years.

This book is a paperback edition of his widely acclaimed 2004 book about globalization. In it he answers the critics of globalization who point to its dark side. Bhagwati argues that many of these criticisms are exaggerated or simply wrong.

Bhagwati begins by recognizing that the discussion of this subject is often highly emotional, with fears masquerading as evidence and neither side listening to the other. He listens carefully to the anti-globalization advocates, articulates their concerns, and then addresses those concerns. In particular, many critics claim that globalization lacks a human face. By this they mean that economic globalization has adverse social consequences. Bhagwati rejects this notion but still addresses the social concerns that the critics cite. As he puts it, he discusses "the design of institutional changes, both domestic and international, that are necessary to make the generally good effects of globalization even better."

Bhagwati's stature as an economist and his careful arguments make his rosy view believable. If you wish to hear an informed argument for the benefits of globalization, this is the book to read. 

Globalization and Its Enemies by Daniel Cohen (MIT, Cambridge MA, 2006, 256pp, ISBN 0-262-03350-X, mitpress.mit.edu, $27.95)

Daniel Cohen is a professor of economics at the École Normale Supérieure, an economic advisor to the French prime minister, and an op-ed columnist for Le Monde. Like Thomas Friedman in The World Is Flat (Micro Review, May/June 2005), Cohen sees todays globalization as the third wave of a process that began with the Spanish conquistidors.

Globalization has not usually brought wealth. India was just as poor in 1913 as it was in 1820. Globalization has also brought terrible consequences, but these have often been completely unintentional. Cohen cites Germaine Tillion's account of the impoverishment of an Algerian village as a result of French actions to eradicate malaria and typhoid and to reduce the village's isolation. Twenty years later, the lack of disease had led to a population explosion. Shepherds increased the size of their flocks, destroying the soil. The roads to the outside allowed some people to become richer by exporting their sheep, while others grew poorer. The traditional societal values disappeared.

According to Cohen, the enemies of globalization fall into two camps: those who decry the westernization of the world and those who see it as a battle in the global class struggle. Both camps share the view that globalization imposes a model that people do not want. But Cohen believes the opposite. Global communication lets people all over the world see the films and television programs of the wealthy nations. Many wish to share in the lifestyle those programs depict, but they see no way to do so.

Cohen sees globalization as proceeding efficiently in the northern hemisphere but not in the southern. He cites Jared Diamond's Guns, Germs, and Steel (Norton, 1996) to explain why this is true.

One of the most contentious issues in globalization is intellectual property. For example, the global AIDS epidemic is manageable in the north but runs rampant in the south. The difference is the general availability in the north of drugs to control the disease. Intellectual property laws make these drugs difficult to obtain in the impoverished south.

This small book contains many interesting ideas and uncommon points of view. I recommend it.  

Database Design

The Art of SQL by Stéphane Faroult with Peter Robson (O'Reilly, Sebastopol CA, 2006, 367pp, ISBN 0-596-00894-5, www.oreilly.com, $44.99)

SQL (no longer an acronym) is the standard language for posing queries to databases. Faroult is a database consultant who has worked on query performance issues for more than 20 years. He regards each new performance challenge as a battle to be fought against an army of database rows. He titled his book as an allusion to Sun Tzu's Art of War. He hopes to pass on his "battlefield" experience to help you write good SQL code. He carries the battle metaphor into his text. For example,

The way that we have to attack that data depends on the circumstances and conditions under which we have to fight the battle. Our attack will depend on the amount of data from which we retrieve our result set and on our forces (the filtering criteria), together with the volume of the data to be retrieved.

Faroult takes you through all of the aspects of performance tuning -- from creating a good design to working with a bad one. He covers a set of standard SQL situations and describes patterns to handle them. He even explains the basic idea of relational databases and shows how using the model correctly can result in code that performs well.

Occasionally, Faroult breaks out a principle and displays it with an owl icon. Examples include the following:

• A confused query can confuse the optimizer. Clarity and suggested joins can help the optimizer provide good performance.
• To reduce the sensitivity of queries to increases in the volume of data, operate only on the data that is strictly necessary at the deeper levels of a query. Keep ancillary joins for the outer level.
• There is no need to code explicitly what the database performs implicitly.     

Tuning the performance of database applications can be a dull subject. Faroult presents it in an interesting way. If you write database applications and you've never studied performance tuning, you should read this book.

Interaction Design

In the Sept/Oct 2000 Micro Review, I looked at Alan Cooper's The Inmates Are Running the Asylum. That book presents the business case for a proposed new profession called interaction design. At that time Cooper promised a subsequent book to explain how to do interaction design.

About Face 2.0 -- The Essentials of Interaction Design by Alan Cooper & Robert Reimann (Wiley, Indianapolis IN, 2003, 504pp, ISBN 0-7645-2641-3, www.wiley.com/compbooks, $35.00)

In 1992 Alan Cooper gave up programming to devote himself to making products easier to use. The first fruit of this effort is his highly regarded book, About Face: The Essentials of User Interface Design (IDG, 1995). 

While Cooper believes that the design principles in About Face are right, he has decided that the audience is wrong. The book starts from the premise that programmers, by default, do most user interface design. As a result, Cooper talks primarily to them, trying to help them design good interfaces. Unfortunately, however, even though programmers would like to design good interfaces, they don't have the time, and often don't have the skills to do so. Moreover, programmers face an overwhelming conflict of interest. 

Competitive demands force programmers to push their systems and their tools beyond their limits. To survive, they must simplify the development process. Making programs easy to use conflicts with making development easy. Programmers have no time to develop  interfaces that mirror users' views of the task. They choose an easy-to-develop interface that mirrors the program's inner workings. Programmers understand the interfaces that result, so they don't see why those interfaces confuse and frustrate users.

The subtitle of the 2.0 version shows the change of audience. Now he is writing for interaction designers. The 3.0 version will be for the same audience, but with more emphasis on online interactions.

This book is much too dense to summarize. The authors present a comprehensive view of the strategy and tactics of designing software that focuses on the needs of users. If you'd like your software to focus on the needs of your users, you probably have a long row to hoe. Reading this book would be a good first step.

Media

Deep Time of the Media -- Toward an Archaeology of Hearing and Seeing by Technical Means by Siegfried Zielinski (MIT, Cambridge MA, 2006, 304pp, ISBN 0-262-24049-1, mitpress.mit.edu, $33.95)

Zielinski is a professor of media and communication studies. In this book he describes a field of his own invention: media archaeology. 

The highly respected science writer John McPhee coined the term "deep time" as an analog to deep space (Basin and Range, 1981). It refers to things so long ago that our brains cannot grasp the magnitude of the interval. We are in deep time when we consider the age of the Earth or the lengths of geological ages. To this concept, Stephen Jay Gould added another dimension that represents biological diversity (Wonderful Life, 1991). Zielinski's deep time of the media is relative to internet time. From that standpoint, the 1500s are ancient. That is where his archaeological investigations begin. The book describes his digging methods and the discoveries he unearthed. A collection of skulls of female Italian criminals seems to have little to do with what we think of these days as "the media," but Zielinski connects them and their collector, Lambroso, to early twentieth century films.

With nearly a hundred pages of notes, bibliography, and index, this is an academic book. Its dry style follows the standard for such books. Yet, Zielinski manages to convey the excitement of finding the turning points that push media history in one direction rather than another. The fascinating illustrations make the book pleasant to page through. 

The Singularity is Near, My Job Went to India

This article appears in slightly different form in the January/February 2006 issue of IEEE Micro © 2006 IEEE.

The Future Will Be Here Soon

This time I look at two books that deal with adapting to trends. One conjectures about how we will adapt to the accelerating pace of technology when that pace outstrips our biological limitations. The other provides sound advice for dealing with an immediate situation, the globalization of technology-based commerce.   

The Singularity is Near: When Humans Transcend Biology by Ray Kurzweil (Viking, New York NY, 2005, 672pp, ISBN 0-670-03384-7, $29.95)

When Ray Kurzweil wrote his first book, The Age of Intelligent Machines (MIT, 1990), he brought to it a history of more than twenty years of creating successful artificial intelligence (AI) applications. As a high school student in the 1960s, he appeared on the TV program I've Got a Secret and played a piece of music that his homemade computer had composed. At MIT, he used AI techniques to match high school students with potential colleges. After graduating, he developed optical character recognition software, reading machines for the blind, and computer-based musical instruments. All of these developments became commercial successes.

Kurzweil's second book, The Age of Spiritual Machines (Viking, 1999) enters the philosophical debate about consciousness, feelings, and whether machines can exhibit these essential human characteristics. Kurzweil's view is that they might not do so now, but it's only a matter of time. That brings us to the current book.

The singularity that Kurzweil refers to occurs at a time, perhaps a few decades from now, when the exponential growth of technology will seem nearly vertical to those of us who are still limited by our biology. The accelerating rate of change in our society is a commonplace. We have been accommodating it for centuries, but it has gotten harder lately. The only way that most of us can keep up is by depending upon such manifestations of computer technology as cell phones, instant messaging, search engines, and electronic mail. Kurzweil believes that the rate of change will continue to grow and that our dependence on technology will evolve into something much more profound.

By Kurzweil's definition, you are a singularitarian if you understand the singularity and have reflected on its consequences for your life. Charlie Kam captured the essence of this book by adapting a Gilbert & Sullivan song (from Pirates of Penzance, 1879):

I am the very model of a Singularitarian 

I'm combination Transhuman, Immortalist, Extropian, 

Aggressively I’m changing all my body’s biochemistry 

Because my body's heritage is obsolete genetically, 

Replacing all the cells each month it's here just temporarily 

The pattern of my brain and body’s where there's continuity, 

I'll try to improve these patterns with optimal biology, 

(“But how will I do that? I need to be smarter. Ah, yes…”) 

I’ll expand my mental faculties by merging with technology, . . .

You can read the lyrics and listen to the whole song by following a link from www.KurzweilAI.net.

Kurzweil attributes much of his commercial success to his ability to predict and adapt to future technological capabilities. Even if you don't believe Kurzweil's conclusions, this book gives an insight into the kinds of research and reasoning he uses to make such predictions. He extrapolates trends in innovation, fabrication, and even software development to conclude that if we can keep ourselves alive until the singularity, we will live for an indefinitely long time. Doing this, as the Charlie Kam song suggests, requires us to understand life and consciousness differently from the way most people view these manifestations of life today.

When Scottie beams Captain Kirk up, Kirk dematerializes where he is and reappears on the starship Enterprise. Each of his atoms is destroyed and the information from that atom is used to produce a corresponding atom on the starship. The Captain Kirk who is now on the starship has complete recall of the adventure from which he just returned. The singularitarian of the song has similarly been "beamed up" to a new, better hardware platform that can more effectively support the patterns that define his identity. That new hardware platform will enable him to leave Earth and spread human intelligence, which will then be growing at a vastly increased rate, throughout the universe.

Leaving aside any reservations we might have about the desirability or details of this scenario, we also have to consider the possibility that negative forces might push the future in a different direction. In his April 2000 Wired Magazine article, The Future Does Not Need Us (Micro Review, July/August 2000), Bill Joy points out that humanity, so far, has muddled through the problems of technological change. But technology is becoming more powerful, more potentially destructive, and more widely accessible. The chance that humanity will survive its side effects, accidental consequences, or malicious misuse, drops from the near certainty of the past to a lower, more frightening, level.

Joy considers three technologies in which our progress is quickly outpacing our ability to control them: genetics, nanotechnology, and robotics (GNR). He calls attention to some of the possible consequences of these technologies -- plague, intelligent germ warfare, out-of-control self-replicating robots, and many others. Some of the consequences seem highly unlikely. Others seem likely. Many are potentially catastrophic, perhaps even fatal, to humanity.

Kurzweil and Joy agree on the dangers, but they disagree on how to deal with them. Joy's proposal is to restrict GNR work until we have mechanisms in place to prevent bad consequences. Kurzweil's approach is to accelerate GNR work in order to avert catastrophes and solve humanity's problems.

Kurzweil dedicates a substantial portion of his book to answering objections like Bill Joy's. These objections have come in response to his earlier books and to earlier expressions of the ideas in this one. I found it very interesting to read these objections and Kurzweil's answers.

Whatever you think about the promise and dangers of the advance of technology, you can learn a lot by reading this book.

My Job Went to India: 52 Ways to Save Your Job by Chad Fowler (Pragmatic Bookshelf, Raleigh NC, 2005, 196pp, ISBN 0-9766940, www.PragmaticProgrammer.com, $19.95)

Chad Fowler is a programmer who has lived and worked in both India and America as an employee of large multinational companies. Like Tom Friedman in The World Is Flat (Micro Review, May/June 2005), Fowler says that the way for U S workers to contend with a global marketplace in information technology is to take steps, individually and as a country, to make themselves more competitive. This book focuses on the steps that workers can take individually.

Incidentally, Ed Miracle, the painter who created the original cover art (dropped in later editions because of a copyright dispute) for Tom Friedman's The World Is Flat, has just brought out another delightful lithograph called Intelligent Design. It is subtle and should not offend people on either side of that controversy. You can order it from www.miraclesart.com/.

  

Fowler does not bash Indian workers. He admires their hard work and determination. Friedman, delighting in a pun and a cultural statement, offers approaches to make you untouchable. Fowler does not have Friedman's global view, but he is far more knowledgable than Friedman about the everyday realities of being a programmer. Like Friedman, he knows that American workers cannot compete solely on price. He offers 52 short but detailed ideas about how to compete globally.

While Fowler's book is informed by his experiences in India and America, much of his advice would have been just as valid twenty years ago. The boom in information technology leading up to 2000 made it easy for American workers to ignore the fundamentals and still do well. This book calls for a return to fundamentals. Fowler wants you to view your career as an exercise in creating and selling a product. To be successful at this you must choose your marketplace, then invest in, build, and market your product.

The first 41 of Fowler's 52 ways to save your job tie directly to these four tasks. The remainder are along the lines of Stephen Covey's seventh habit of highly successful people: sharpen the saw (Micro Review, Sept/Oct 2002). That is, they help you keep your edge.

Fowler recognizes that collaboration is a key competency for anyone who wishes to compete in the global marketplace. He berates the fears that make some American workers reluctant to share their wisdom with their Indian counterparts. Companies that have such internal distrust between their American and Indian teams are less effective, and ultimately less successful, than companies in which the teams work together.

Fowler's 52 essays are down to earth and uncompromising. You can't make things better if you don't assess the current state of affairs honestly. Most essays conclude with a list of ways to act on what you learned. These are small but important tasks. You can accomplish them in a reasonable length of time, and they take you outside the daily routine that can lead to long term decline. 

For example, in one of his essays Fowler points out that even if you are on the bleeding edge of the current wave, you're probably behind on the next one. The action item at the end of that essay calls for you to carve out two hours each week to research new technologies and start to develop skills in them.

Another example is an essay in which Fowler points to the open source movement as a model for solving many of the collaboration problems that arise within multinational teams. The action item at the end of that essay is to get involved in an open source project to help you learn how to collaborate.

Fowler calls The Pragmatic Programmer by Dave Thomas and Andy Hunt (Micro Review, Jan/Feb 2000) a catalyst for his career. The current book follows that excellent model in providing a pragmatic approach to dealing with globalization. You should read it.