Effective Java, Thoughtworks Anthology, Javascript: The Good Parts

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

Software Development Patterns

This time I look at three books about programming. None of them has the word "patterns" in its title, and none of them claims to deal with patterns or best practices, but that is what they are all about.

Effective Java, 2d ed by Joshua Block (Addison-Wesley, Upper Saddle River NJ, 2008, 368pp, ISBN 978-0-321-35668-0, $49.99)

When I reviewed the first edition of this book (Micro Review, July/Aug 2002), I had never met Josh Bloch. Several years later, however, I was visiting the Google booth at JavaOne, when Josh came up to me and told me that my review had launched his book. He believed this because when my review appeared, his book had already been out for a year with modest sales, and his sales then increased substantially. I don't believe that my review had much to do with it. The book has a lot of substance, and it takes time for people to digest it and spread the word. Nonetheless, I recently took advantage of his gratitude to persude him to give me a copy of the new edition.

The first edition contains 57 short essays, called items. The new edition has 78 items. A few of the original items have disappeared, and Josh has added items to reflect the important changes to Java since 2001. He was a major player on the teams that developed generics, enum types, annotations, autoboxing, and the Java 5 for-each loop and concurrency library. 

In 2004, Josh moved from Sun to Google, where he continues to guide the evolution of the language but now also develops Java libraries that use the new features. Thus he knows Java both as a language designer and a language user. There is probably no other person who could have written this book with the same degree of insight and experience.

If you ever have a chance to hear Josh talk, don't miss it. He is an excellent teacher, because he explains complex points clearly. That talent shines through the pages of this book as well. The items that Josh discusses are quite complex, even abstruse. Yet any experienced Java programmer can understand them.

My review of the first edition highlights many good points that are still good in this one. What I concluded about the first edition remains true of this one. Every bit of this book is essential for Java designers. Reading this book before you start delivering products can easily repay its cost thousands of times.

The ThoughtWorks Anthology -- Essays on Software Technology and Innovation by members of the ThoughtWorks staff (Pragmatic Bookshelf, Raleigh NC, 2008, 234pp, ISBN 978-1-934356-14-2, $38.95)

ThoughtWorks is a software development firm that specializes in fighting software bloat. To this end they have developed techniques for programming, building, testing, and delivering applications efficiently. The essays in this book present several of these techniques.

ThoughtWorks's founder, Roy Singham lays out his vision in the first essay. He talks about "the last mile" of putting a system into production. The expression "the last mile" comes from the telecommunications industry. The high speed backbone of the global internet slows down when it reaches the "last mile" of copper wire that brings bits to and from most individual customers. People have been talking about this problem for decades, but customers have seen few improvements.

For Singham, the last mile starts when the software meets all of its functional requirements. It ends when it is in place, delivering value to the customer. Development teams can bring a project to a conclusion rapidly and efficiently because of their tools and methodologies. Customers then begin a long, slow, expensive process. They must ensure that the new software can handle the expected workload, work well with other systems, interact with existing data without corrupting it, and protect against all sorts of unauthorized use or attacks.

Currently, developers derive functional requirements from end users who, ideally, have continual contact with the developers throughout the project. Singham suggests adding the last mile tasks to the functional requirements and involving the last mile stakeholders in the project from its inception. This should lead developers to automate much of the last mile process, just as they routinely automate builds and testing. 

In telecommunications, the Holy Grail of the last mile problem is a means by which the internet can reach any customer at full speed (for example, fiber to the home). For software, Singham sees the Holy Grail as versionless software, a means by which developers can add features directly to production systems "on the fly," without fear of unintended consequences. Neither of these visions will come to pass any time soon.

Twelve more essays round out this book. They deal with programming, managing development, maintaining web applications and service oriented architectures, and building and testing systems. Having worked with large, convoluted Ant scripts, I especially appreciate Julian Simpson's essay on refactoring techniques for such files.

In the 1970s I worked with the late Rudolph Langer, who built a number of special purpose languages, usually on top of macro assembly languages. One of these, for example, facilitated designing pinball machines. Another made it easy to design optical forms to enable users to enter data visually. Nowadays we might call these domain specific languages (DSLs). Martin Fowler's essay explains how to use Ruby to create a DSL.

One of my favorite essays is Jeff Bay's "Object Calisthenics."  He proposes an exercise in which you must write a 1000 line Java program using the following extremely strict coding standards:

• Use only one level of indentation per method.
• Don't use the else keyword.
• Wrap all primitives and strings.
• Use only one dot per statement.
• Don't abbreviate.
• Keep all entities small.
• Limit classes to two instance variables.
• Use first class collections.
• Don't use getters, setters, or properties.

Bay explains the points that he intends this exercise to make. He wants you to encapsulate data, use polymorphism properly, avoid duplication, and appropriately model the problem that you want the code to solve. 

Like most books from the Pragmatic Bookshelf, this one is full of good practical advice. If you develop software, this one should be on your bookshelf.

JavaScript: The Good Parts -- Unearthing the Excellence in JavaScript by Douglas Crockford (O'Reilly, Sebastopol CA, 2008, 170pp, ISBN 978-0-596-51774-8, www.oreilly.com, $29.99)

Douglas Cockford is a JavaScript architect at Yahoo, where he introduced and maintains the JavaScript object notation (JSON) format. He is deeply steeped in the intricacies of the JavaScript language. The target audience for this book consists of highly experienced software designers and architects who are probably working on Ajax applications. If you do a little JavaScript programming to spruce up your website and are looking for a few tips and tricks, this is not the book for you.

Early browsers used Java applets, but this technology did not catch on. JavaScript went, in too short a time, from a rough draft of a language to the main language recognized by browsers. Subsequent revisions have added features, but the basic language design remains unpolished. Cockford refers to JavaScript as a "beautiful, elegant, highly expressive language that is buried under a steaming pile of good intentions and blunders."

The part that Cockford considers beautiful is what he calls Lisp in C's clothing. By this he means that at heart JavaScript is a functional language like Lisp or Scheme, but its syntax resembles that of C. JavaScript has objects but not classes, which confuses many casual JavaScript programmers. You can create objects from prototypes, but you can also freely add attributes and methods. You can also define objects as literals, simply by listing their attributes and methods.

Cockford sets out to show you how to create JavaScript programs that use the parts of the language that he likes and avoid the parts he considers bad. Unfortunately, you can't avoid all of the bad parts (for example, global variables, the lack of block scoping, the poor way it handles Unicode). 

Cockford's explanations of how to avoid the bad parts entail sophisticated programming. His examples require careful reading, and real mastery probably takes a lot of practice. Cockford characterizes the book as follows:

"This book is small, but it is dense. There is a lot of material packed into it. Don't be discouraged if it takes multiple readings to get it."

Excluding the appendixes and the index, the book is 100 pages long. You probably won't read it in one sitting, but it will repay your effort. It doesn't spend much time explaining the bad parts. If you want to use those, Cockford says, read any of the other JavaScript books.

If you are an experienced programmer familiar with many programming languages but forced to do serious development in JavaScript, this book may save you an enormous amount of trouble.

Adobe for Technical Communicators, Switching to the Mac

This article appears in slightly different form in the March/April 2008 issue of IEEE Micro © 2008 IEEE.

This time I talk about two subjects that are not the way they once were and may change again tomorrow.

Adobe Technical Communication Suite (Adobe, San Jose CA, www.adobe.com, $1599.00)

Fifteen years ago, the tools of the technical communicator's trade came from many companies. The most important tool for creating technical manuals was FrameMaker from Frame Technology. For newsletters, marketing pieces, and other short documents, writers also used the more agile PageMaker, a tool for composing pages, from a company named Aldus. RoboHelp, from Blue Sky (later called eHelp) emerged as the tool of choice for creating online help systems. When web browsing became popular, Macromedia brought out DreamWeaver, the HTML editor of choice. Macromedia also developed Flash technology, one of the simplest ways to add animation to online content.

Starting in the early 1980s, a company called Adobe invented Postscript, the display language that now sits inside virtually every laser printer. They also developed the premier tools for manipulating vector and bitmapped graphics: Illustrator and Photoshop. Postscript is great for the insides of printers, but not so good for interchange and multimedia, so in the early 1990s, Adobe developed Portable Document Format (PDF). More than 90% of personal computers have software to read PDF files.

When many companies serve the same customers with different products, there is usually one outcome -- one or more companies grow by absorbing the others, and soon the customers have a small number of full service suppliers.  Adobe now owns all of the products mentioned earlier in this column. Only Microsoft has a plausible claim to being a competitor.

Having accumulated a set of products for the same audience, Adobe has taken the added step of making them work together smoothly. The Technical Communication Suite (TCS) consists of FrameMaker, RoboHelp, Captivate, and Acrobat 3D. If you buy them as the TCS, they work more efficiently together, and cost less, than if you buy them separately. 

For technical communicators, FrameMaker and RoboHelp are the heart of the TCS. Captivate, which simplifies creating Flash-based demonstrations and training, may become more popular as buyers of the TCS learn how to use it. Acrobat 3D, for most technical communicators, is essentially the same as Acrobat, but with a flashy new feature (embedded 3D graphics) that most of them will never use.

FrameMaker is the tool most technical communicators choose to create books. It manages the chapters, appendixes, indexes, and so forth in a structure called a book file. It provides ways to maintain consistent styles and formats throughout the final document. It provides a facility for including some text conditionally, based on attribute values applied to the document at publication time. Up until the TCS, FrameMaker worked with a product called WebWorks Publisher to produce HTML output from the same source files. In the TCS, RoboHelp provides HTML publishing capabilities for FrameMaker.

I first reviewed FrameMaker in the May/June 1993 Micro Review. Unlike the current version, FrameMaker 3.0 worked essentially identically on both Macintosh and PC, as well as on the Unix systems for which Frame Technology had originally designed it. FrameMaker 8 and the TCS work only in a Microsoft Windows (XP or Vista) environment. Adobe has given no indication that they will ever support this product in the Macintosh environment. On the other hand, FrameMaker 8 has a variety of new or improved features, when compared with FrameMaker 7.2:

• Change tracking -- at last!
  
• A tabbed view to facilitate working with many source files simultaneously
  
• Improved Unicode support
  
• Spelling and hyphenation dictionaries for 30 languages
  
• Better XML support (but still no DTDs or schemas)
  
• Support for Darwin Information Typing Architecture (DITA)
  
• Integration of rich media (for example, Flash or 3D graphics)
  
• An updated Frame Developer's Kit (FDK)
  

Like any new version, FrameMaker 8 has given me a few unpleasant surprises. I encountered, as others have reported, occasional crashes or failures to complete requested operations. However, I did two serious projects with FrameMaker 8 and was able to get past the occasional problems to produce correct PDF output.

Most technical communicators who produce online help use RoboHelp to do so. It facilitates building a body of information units called topics. It provides ways to maintain consistent styles and formats, and it manages all the ways end users can navigate to and among the topics. There are many standard formats for online help -- nowadays all based on HTML -- and RoboHelp supports all of them from a single source.  

I first reviewed RoboHelp (version 2.6) in the Sept/Oct 1994 Micro Review. Over the succeeding years, new RoboHelp versions came out much too frequenty, leading to internal problems in the product. According to Mike Hamilton, a former key eHelp employee, Adobe inherited a code base in December 2005 that needed massive reorganizing and bug fixes. Another problem with RoboHelp was its output of a proprietary form of HTML, based on the notorious tags. Adobe began to attack these problems with RoboHelp 6. They have now brought out RoboHelp 7 as part of the TCS.

In the TCS, RoboHelp works well with FrameMaker. Like FrameMaker, RoboHelp provides styles, variables and conditional text. You can define a mapping between FrameMaker's sytles, variables, and conditions and RoboHelp's. The mapping facilitates importing FrameMaker output into RoboHelp. You can import FrameMaker files into RoboHelp by reference, so that RoboHelp receives subsequent changes to the FrameMaker file, or you can import as a copy, so that subsequent changes to the FrameMaker file do not affect the RoboHelp version.

RoboHelp can also import files of a variety of formats, including Microsoft Word 2007, as well as earlier Word formats. It converts all imported files into HTML and provides a built-in HTML editor for manipulating them.

RoboHelp projects generally contain large numbers of files, sometimes worked on simultaneously by more than one person. RoboHelp comes with a source control facility that provides locking, history, and a means to compare versions. 

Captivate is new to most technical communicators. It provides ways to create simulations (annotated animated screen captures) and training materials, including quizzes. Captivate produces Flash output, so that file sizes are relatively small. It can even import PowerPoint presentations and convert them to Flash.

Acrobat is an essential tool for technical communicators. It has many quirks, and there are gurus to help you deal with them (see Micro Review Sept/Oct 2004). It provides a way of publishing reasonably sized files representing printed manuals. It provides a variety of means for reviewing and annotating documentation. 

In the TCS, Acrobat enables you to embed three dimensional figures -- the output of common computer-aided design programs -- in PDF files. Readers can then manipulate the figures without special software. You can also embed Flash, sound, and other multi-media formats. 

The way I use Acrobat, I've noticed little difference since moving to the TCS. My one complaint is that printing generally takes longer. There are some documents I print routinely that used to come out quickly with my old version of Acrobat but now take so long that the printer manager sends back an error message saying that the document failed to print. If I ignore the message, the document eventually prints. I've only tried this with one printer -- my ten-year-old HP LaserJet 4000 -- so perhaps it's not a general problem.

Adobe has made it easy for technical communicators to adopt the TCS. The bundle price essentially gives you some components at no cost. Adobe also offers generous discounts to owners of earlier versions of any of the components. It also offers student discounts. 

By bundling the products of the TCS, Adobe makes it less likely that a competitor to any of these products will become a new standard. An example of such a competing product is Flare, from MadCap Software. When Adobe acquired Macromedia, which had recently acquired eHelp, members of the RoboHelp team left Adobe to found MadCap. This gives MadCap Flare immediate credibility among technical communicators. Adobe's bundling of RoboHelp into the TCS, however, creates a large barrier to a successful challenge to RoboHelp by Flare. 

If you produce technical documentation, you probably already use FrameMaker or RoboHelp. You should take advantage of this package to obtain the benefits of the greater integration. It will also give you Captivate and the 3D features of Acrobat, essentially free.

Switching to the Mac, Leopard Edition: The Missing Manual by David Pogue (O'Reilly, Sebastopol CA, 2008, 604pp, ISBN 978-0-596-51412-9, www.oreilly.com, $29.99)

In 1984 I got my first Apple Macintosh computer, and I used Macs almost exclusively until the early 1990s, when Windows 3.1 became a serious competitor. Gradually I switched almost entirely to PCs. I haven't done any serious work with a Mac in many years.

Recently I had occasion to borrow a Mac to review some Mac software. I found the experience extremely frustrating. I know that a Mac can do essentially everything a PC can do, but they do it differently enough that I felt like a beginner. It reminded me of times when I've tried to express myself in a language I don't know very well. I know what I want to say, but I don't know how to say it in that language. My mind races ahead, but my tongue cannot follow. This is the problem that David Pogue attacks first. The first four chapters tell you how to accomplish things on a Mac that you already know how to do on a PC.

If you're not just visiting, but actually emigrating from the PC to the Mac, there is still a lot more to do. You need to move your files and get used to a whole new set of application programs. While some programs work exactly the same in both environments, you may find yourself using a different browser or mail program. Many programs work almost exactly the same. Pogue lists the tiny differences to be aware of in dozens of common programs.

The remainder of the book is not so much about switching as about understanding how the Mac OS X operating system works. For example, you probably have a limited view of how networking or system preferences work in the Windows environment. Pogue explains the somewhat more comprehensible Mac versions of these subjects.

If you are a PC user, and you need to use a Mac or are considering moving permanently to a Mac, this is an essential book. Don't leave your PC without it.

Young Investigator, Agile Restrospectives, Oracle Essentials

This article appears in slightly different form in the November/December 2007 issue of IEEE Micro © 2007 IEEE.

Advice for a Young Investigator by Santiago Ramón y Cajal, translated by Neely Swanson and Larry W. Swanson (MIT, Cambridge MA, 1999, 172pp, ISBN 0-262-68150-1, mitpress.mit.edu, $19.95)

Santiago Ramón y Cajal (1852 - 1934) shared the Nobel Prize in Physiology or Medicine in 1906, just over a century ago. He established the structure of the brain and nervous system as networks of neurons connected by synapses.

In 1897, on the occasion of his induction into a Spanish scientific academy, Ramón y Cajal gave a speech in which he advised young investigators to focus their work in ways that he felt would help them avoid many of the mistakes that he made as he began his own scientific career twenty-five years earlier. The speech eventually evolved into this book, with editions in 1898, 1912, 1916, and 1923.

Ramón y Cajal lived in a time when Spain was not in the mainstream of scientific work. Much of his advice concerns overcoming this obstacle -- learning languages, studying abroad, and so forth. His advice in this area is fascinating to look back on in the light of the shifts of power and influence that occurred in the twentieth century. He pronounced German the most important language for scientists, followed by English and French. He considered Italian to be important too, but so much like Spanish that any Spaniard can read it without difficulty.

The most thoroughly obsolete part of this book concerns how a young investigator should choose and relate to his wife. One of his milder precepts in this area is as follows:

As a general rule, we advise the man inclined toward science to seek in the one whom his heart has chosen a compatible psychological profile rather than beauty and wealth. In other words, he should seek feelings, tastes, and tendencies that are to a certain extent complementary to his own. He will not simply choose a woman, but a woman who belongs to him, whose best dowry will be a sensitive compliance with his wishes and a warm and full-hearted acceptance of her husband's view of life.

Some of Ramón y Cajal's advice is as apt today as it was a century ago. Some of the examples he gives are tied to old technologies, but the principles are still correct. For example, he warns young investigators against undue admiration of authority. Ultimately, they must find their own way and dethrone established wisdom, just as Galileo refuted Aristotle's view of gravity and Copernicus displaced Ptolemy's view of the universe.

Ramón y Cajal also warns agains the fallacy that everything important has been discovered. The twentieth century is filled with counterexamples to that nonsense.

In his recitation of desirable intellectual qualities, Ramón y Cajal concurs with the twenty-first century view in some areas, but perhaps not entirely in others. For example, he advocates independent judgment and concentration. Few today would argue with those qualities. On the other hand, he lists passion for reputation and patriotism among his desirable intellectual qualities. Here his arguments are not as persuasive.

Ramón y Cajal adheres to the "hard work" theory. He feels that most young investigators can do good work, but that lack of self-confidence leads many to fail. 

In Devices of the Soul (Micro Review, Jul/Aug 2007) Steve Talbott says that self forgetfulness is the reigning temptation of the technological era. He complains that we do not observe aspects of the world around us that fail to fit into our preconceived models. Ramón y Cajal would agree. He advocates specialization in the sense of mastery. His ideal investigator has the same relationship to his craft as the Waorani hunter has to his prey.

This a fascinating book. It gives valuable insights into the changes of the last hundred years, and it contains nuggets of advice that are as valuable today as when Ramón y Cajal wrote them. I commend MIT Press for making it available, and I recommend it to any student of science.

Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen (Pragmatic Bookshelf, Raleigh NC, 2006, 192pp, ISBN 0-9776166-4-9, www.pragprog.com/titles/dlret, $29.95)

In the May/June 2001 Micro Review, I reviewed Project Retrospectives by Norm Kerth. That book proposes a dramatic improvement over the perfunctory "post-mortems" that software teams sometimes engage in when they have finished a project. Derby and Larsen have adapted Kerth's retrospectives to work with iterative and incremental development methods. Their retrospectives cover a short stretch of development -- perhaps a few weeks -- and drive changes to goals and processes for the next short stretch.

The project retrospectives that Kerth describes can entail a week spent at a resort. Derby and Larsen describe a process that proceeds on a much tighter schedule -- perhaps an hour or so. Short meetings, like short letters, are hard to achieve. They require focus and discipline. This book defines a structure and timeline for such meetings. By concrete examples, it shows why each element of the structure is important and how to meet the goals of that element within the allotted time.

As regular readers of this column know, Esther Derby is one of the people who work with Gerald Weinberg to produce the annual Amplify Your Effectiveness conferences. These conferences emphasize the human side of software development, and this book does the same. It shows how to identify and solve many team interaction problems that occur again and again in development projects.

If you engage in any sort of agile development, you should read this extremely concrete and practical handbook. 

Oracle Essentials, Fourth Edition by Rick Greenwald, Robert Stackowiak, and Jonathan Stern (O'Reilly, Sebastopol CA, 2008, 406pp, ISBN 0-596-51454-9, www.oreilly.com, $39.99)

Jonathan Stern, the author most responsible for the original edition's structure and clarity, died in March, 2007. The remaining authors dedicate this edition to him.

A few years ago I reviewed the second edition of this book (Micro Review, July/August 2001). As I noted then, I love books like this. I wish there were more of them. I spent over a year working with the Oracle server technology publications group and wrote some of the documentation that the earlier edition of this book is based on. The few hours that I spent reading this book gave me a much better sense of all the pieces and how they fit together than I ever achieved reading or writing Oracle documentation.

This edition does not differ greatly from earlier editions. It covers the new features of Oracle 11g: caching of query results, automatic memory management, real application testing (analyzing data from production runs), total recall (a data archive that allows querying "as of" a specified time), active data guard (simultaneous query and update of a standby database), and many other changes and additions. The authors integrated the new features into the book at the appropriate places, making the book look as if it were written from scratch for this edition.

The economics of the computer book business seem to favor books that cover a wide variety of features in a cursory way. Many books provide excellent task-oriented instructions for end users or even administrators, but give them little insight into the underlying structure and concepts.

The authors of Oracle Essentials follow a different path. They present a concise, coherent picture of the entire Oracle system. This picture does not cover every feature of Oracle, nor does it cover any feature in complete depth. The picture is broad enough and deep enough to give you a good understanding of the main structures, processes, and issues involved in planning for and deploying Oracle, developing and optimizing schemas and applications for it, and administering its use.

One of the hardest tasks in working with Oracle is understanding the kind of big picture that this book presents. Thousands of highly skilled software developers have worked on the system over a period of more than twenty years. Inevitably, layer upon layer of enhancements have distorted and obscured the clarity of the original design. Furthermore, the system is so large and complex that people who start to work with it usually join a group that specializes in one aspect of it. Even the oldtimers in the group may not know much about the rest of the system. And because they are comfortable in their corner of the product, they may not even consider it important to orient newcomers to the whole system.

The difficulty with this situation surfaces when different groups of specialists must work together to solve a common problem. Activities ranging from developing new versions of the product to designing new applications suffer from the inability of groups of specialists to understand one another's problems and issues. For that reason, I think this book will do as much good within the walls of Oracle Corporation as it will outside.

If you work with any aspect of Oracle, or if you'd just like to understand the ins and outs of an important complex technology, this book is a must. 

Devices of the Soul

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

Thinking About Technology

Devices of the Soul by Steve Talbott (O'Reilly, Sebastopol CA, 2007, 298pp, ISBN 0-596-52680-6, www.oreilly.com, $22.99)

In this book, Steve Talbott distills and sharpens a message he has been working on for a long time. Here is an excerpt from my review of Talbott's The Future Does Not Compute (Micro Review, Nov/Dec 1995):

While many pundits sing the praises of the coming global village, Talbott wants us to examine their unspoken assumptions. Many seem to be saying that simple technological tools can guarantee freedom and privacy, make learning and personal growth easy, and build strong democratic communities.

Talbott sees this as wishful thinking -- magical, automatic solutions to complex human problems. He sees the effects of the new technology as an extension of a trend that runs through most of the twentieth century. We spend more and more of our lives "running on automatic."

Since 1995, Talbott has edited an online newsletter at www.netfuture.org. Most of the material in his new book appeared first in that newsletter. Perhaps for that reason, this book has many interwoven themes that all reinforce the basic message: Self forgetfulness is the reigning temptation of the technological era. 

I often watch the CNBC program Mad Money with former hedge fund manager Jim Cramer. The other day Cramer, who likes to make classical allusions, was talking about the many voices trying to frighten people into the anti-pattern: buy high, sell low. He stuck his fingers in his ears and said, "Don't listen to them, like Ulysses." My fourteen year old daughter and I have been reading the Odyssey, so I told her this. "But that's not what Odysseus did," she replied. "He made his men lash him to the mast so he could hear the Sirens' song." I'm not sure what implications this story has for investing, but it is a key element of a central metaphor of Talbott's book. 

The Sirens sang that they knew all and would tell all to those who approached. Those who listened could not resist approaching, so they perished on the Sirens' rocks. Odysseus saw that the Sirens presented a grave danger. His self-awareness allowed him to perceive the risk and to conceive the clever device that saved him.

Talbott sees the Odyssey as a story of the dawn of technology. Odysseus's growing self-awareness, apparently not so common back then, allowed him to harbor secrets and concoct the many schemes for which he was famous. He conceived and executed the plan of the Trojan Horse, which brought victory to the Greeks in the Trojan War. He devised a complex scheme to free himself and his men from the cave of the cyclops Polyphemus. 

Talbott equates the Sirens' false promise to tell all with today's promises of salvation through digital technology. "You are powerless to affect the technologically mediated future," sing today's Sirens. "Come dull the pain by partaking of its wonders." Talbott believes that we are not analyzing and mitigating against the risks of technology. We are letting the repeated assurances of progress through technology lull us into self-forgetfulness.

Odysseus's technology consisted mainly of mental devices. The golden age that followed Homer's time gave rise to great advances in art, drama, philosophy, mathematics, and science. But the Greeks, except for Archimedes, did little in the area of engineering. By contrast, we are surrounded by gadgets, but we forget that they are human inventions, carrying the aims and assumptions of their creators. This is self-forgetfulness, because we can forget our own aims, assumptions, and skills as we conform our behavior, and even our thinking, to the gadget's requirements.

Talbott contrasts Odysseus, the self-aware contriver, with the cyclops Polyphemus who lived in a simple natural state. While Odysseus moved away from this natural state slowly, today we are almost completely out of touch with nature. We have learned to ignore whatever our mechanisms fail to take account of, thus making us descend to the level of the machines. Holistic medicine, for example, seeks balance, not absence of pathogens. But we do not teach doctors to detect balance, because it is not part of the western model of disease and treatment. The doctors who follow this model cannot see what is evident to the practitioners of, say, traditional Chinese medicine.

The Harvard ethnobotanist Richard Evans Schultes was famous for his qualitative knowledge. He could resolve questions in the field, simply by holding a blossom up to the light. Yet even Schultes was amazed at the ability of the forest residents to distinguish ten different kinds of yagé plants by sight at great distances, even though the distinguishing criteria made no sense in the standard botanical scheme.

Talbott views the history of technology as the history of walking away from ourselves. He describes the enormous skill of Tomo, a Waorani (Auca) hunter who could "knock a hummingbird out of the air and hit a monkey in the canopy 120 feet above the forest floor." In learning to use the blowpipe, Tomo had to develop stealth, physical skills, patience, focused attention, and, most important, a qualitative understanding of the animals he hunted and the forest they lived in. He knew, without thinking about it consciously, how it felt to be the animals he hunted.

Tomo, however, preferred a shotgun -- a vastly inferior weapon for his purposes -- because of the intrinsic attraction of the object itself. This is the same sort of intrinsic attraction I have always felt in hardware stores and, more recently, in electronics stores. In Tomo's case, the shotgun might lead him to specialize in shooting large animals at close range -- a task that requires some, but far from all of his skills. It is not hard to imagine his losing the unused skills over time.

Walking away from old skills and developing new ones is not the problem. This happens whenever people grow and progress. The problem Talbott sees is the direction and emphasis of the change. We often let labor-saving technology do the parts of the job that are easy to automate and simply drop the parts that depend on skills that our machines don't have.

Another central metaphor of Talbott's book is the conversation. Talbott calls for a respectful conversation between humans and nature, and a similar conversation between the technology around us and our aware selves. Talbott's model for conversation is human relations. We grant the autonomy and worth of others, and at the same time we act in ways that affect them. The approach we take in human relations models the approach Talbott suggests in the areas of ecology and technology.

A conversation without preconceptions or artificial boundaries necessitates the risk of offense and misunderstanding. We have limited knowledge of the effects of, say, a new industrial process, an experimental gardening technique, or even a new type of bird feeder. This ignorance mandates that we proceed cautiously, but absolute caution makes progress impossible. The important thing is to listen carefully and openly to the answer. This is essentially the approach Bill Joy advocates in his April 2000 Wired Magazine article, The Future Does Not Need Us. There he warns about genetics, nanotechnology, and robotics (GNR) and the potential catastrophes they might precipitate (see Micro Review, July/August 2000).

Bill Joy often appears paired with Ray Kurzweil, author of The Singularity is Near: When Humans Transcend Biology (see Micro Review January/February 2006). 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. Talbott's approach is much closer to Joy's than to Kurzweil's.

In the conversation between our aware selves and our technology, Talbott raises the question of how our tools should act. Should they act like friends, praising our efforts and offering us companionship? Should they be as unobtrusive as possible, so we can concentrate on the tasks they are helping us with? We can rule out the first one pretty quickly. Hardly anyone likes the Microsoft paper clip. But Talbott regards the second as unhealthy too. Because it is so important to remain conscious of the assumptions and unseen factors that affect us, it's a good idea not to forget about our tools. An invisible tool still embodies the ideals and assumptions of its creator.

Talbott devotes a portion of his book to addressing the views of researchers who, like Kurzweil, paint pictures of a future when computers will think and act like people. He ridicules Rodney Brooks for saying things like "We, all of us, over-anthropomorphize human beings, who are after all mere machines." He convincingly brands Brooks as a bully who argues from ignorance.

He also heaps scorn on certain efforts coming from the prestigious and well funded MIT Media Lab. Computers, in Talbott's view, will think and act like people only if people abandon their humanity and reduce themselves to the level of automatons. The fact that people can imagine being replaced by computers shows how far along that path the Sirens of technology have led them. 

To emphasize the aspects of humanity that computers are unlikely to achieve, Talbott tells the stories of people whose handicaps did little to impair their humanity. I don't go into those astonishing stories in this review, but I hope you will read about them when you buy the book.

Education is another main theme of the book. The essence of education,according to Talbott, is helping children develop their own connections to the world. The Tracker by Tom Brown (Prentice Hall, 1978) tells the story of how an Apache elder, Stalking Wolf, taught Brown about the wilderness. When asked a question, Stalking Wolf would not reply with the requested information. Instead he would say "go ask the mice," "feed the birds," or something of the sort to send his student off on an adventure. 

Our culture, however, works against understanding the world this way. Talbott gives the example of Monty Roberts, who learned to relate to horses in a way that allowed him to persuade untamed horses to do what he wanted, quickly and without force. Roberts, however, was rediscovering what John Solomon Rarey had already published in the mid 1850s. Rarey's work, though sensational at the time, was forgotten, because it did not fit the dominant paradigm.

As Talbott points out, every educator publicly deplores the fact-shoveling model of education, but our educational system moves further and further in that direction. Jane Healy's Failure to Connect: How Computers Affect Our Children's Minds--for Better and Worse (Simon and Schuster, 1998) analyzes the use of computers in elementary school classrooms. Healy sees few benefits, especially for younger children, and many bad consequences. Nonetheless, we continue to computerize classrooms at the expense of programs with greater educational benefit (for example, art, music, physical education, reduced class sizes).

In a chapter called Educational Provocations, Talbott makes blunt assertions about elementary education that he hopes will stimulate discussion. The gist of this eclectic recital is that the push for computers in elementary schools comes from giant computer companies and the parents that they have frightened or enthralled. The justifications are at best unproven and are probably untrue. The change in emphasis that computers produce goes against what educators know. Students need significance, not data. They need individual attention from caring adult mentors, not more sedentary time in front of screens. Finally, nobody has even considered the potential negative effects of the technology itself on developing children. Talbott even questions whether exposing children to the Internet at all is a good idea. Children need safe places in which to develop. The Internet is not a place, and there is no effective way to make it safe.

The fact-shoveling model of education has also brought great harm to higher education. If education is just data transfer, nobody needs to pay $40,000.00 per year to a university. The computer can transfer data much more efficiently than four years of college can. The aspects of education that residence at a four year college is designed to foster are no longer highly valued in the business world. In many jobs, an obedient worker who goes to the help system for just in time learning can be more cost-effective than a worker who has learned to think, introspect, challenge, and do research. In the credentialed society, the hiring manager is happy with fungible degrees based on measurable outcomes like numbers of hours of classes taken or specific scores on standardized tests.

Talbott also addresses the question of privacy. He points out that privacy is not the same as anonymity. It only matters where we know each other well enough to care. If our social functioning is reduced to data interactions, there is nothing for privacy to attach to.

Talbott is not a Luddite. He likes and values the technology he warns us about. He doesn't want us to discard it. He wants us to become fully aware of the tradeoffs between its positive and negative effects. Only with awareness can we make rational decisions.

This book is a highly distilled presentation of more than ten years of Talbott's thinking about these issues. This review only scratches the surface. To do Talbott's ideas justice, you should read the book, look at the works he refers to, and think deeply about the issues. I hope that you will.

Looking Back over 20 Years

This article appears in slightly different form in the March/April 2007 issue of IEEE Micro © 2007 IEEE.

With this issue I start my twenty-first year writing the Micro Review column. Microsoft Windows, the World Wide Web, Java, the Y2K flap, the dotcom bubble, and a new wave of globalization all happened on my watch (not to mention the Loma Prieta earthquake, the Oakland/Berkeley Hills fire, 9/11, the Afghanistan and Iraq wars, the Indian Ocean Tsunami, and Hurricane Katrina).

Quite a lot has changed in our industry since my April 1987 column, in which I reviewed Motorola's manual for the MC68851 paged memory management unit and Danny Hillis's book about the connection machine. That year I reviewed Michael Slater's marvelous book, Microprocessor-Based Design and Maurice Bach's The Design of the Unix Operating System. I also looked at Microsoft Word 3.0.1 (for the Macintosh, of course) and an implementation of Donald Knuth's TeX.

Microprocessors and Computer Architecture 

Over the years I have branched in many directions, but I continue to focus on Micro's core themes. I reviewed the long awaited Hennessy and Patterson book on computer architecture in 1990 and their sequel on hardware/software integration in 1994. I reviewed Mike Johnson's Superscalar Microprocessor Design in 1991. I have reviewed books on cache design, busses, spread spectrum, high-speed digital circuits, logical design, the Pentium architecture, the PowerPC architecture, and more. Especially notable were Muhammad Ali Mazidi's coffee table sized book on the 80x86 architecture and Clive Maxfield's quirky Bebop to the Boolean Boogie (Micro Review Sep/Oct 1995) and its sequel, BeBop Bytes Back (Micro Review Jul/Aug 1997).

Computers and Consciousness

A consistent theme of my columns over the years has been the human mind and how it works -- especially when the workings turn out to be similar to computer architectures. In 1988 I reviewed Johnson-Laird's The Computer and the Mind. This got me into trouble with my friend Bernie Baars, because I never did review his much better book on the same subject, A Cognitive Theory of Consciousness. In subsequent years I reviewed Penrose's The Emperor's New Mind, Dennett's Consciousness Explained, Dyson's Darwin among the Machines, and, in 2004, Dan Lloyd's Radiant Cool -- A Novel Theory of Consciousness. 

If we broaden the subject to include decentralization and self-organizing behavior, we can include my Nov/Dec 1994 column, in which I reviewed Michael Resnick's Turtles, Termites and Traffic Jams -- Explorations in Massively Parallel Microworlds. In that book Resnick puts forth the general theory that Systems don't need a controlling intelligence to achieve purposeful behavior. No leader directs birds to fly in formation or ants to form trails from their nests to food sources. Instead, large numbers of independent entities, each following simple rules, produce the large scale patterns that we observe. This is also, essentially, Dennett's idea of how consciousness works. It is also the theme of Michael Crichton's Prey, which I reviewed in my May/Jun 2003 column.

Globalization

In 1988 I took issue with a blurb on the back of a book about WordPerfect. The blurb quoted Andy Rooney as saying that the author had written the first book about computer software that does not appear to have been translated from the Japanese. I said, somewhat pompously, that the situation that Andy Rooney mocks does not result from an inability of Japanese speakers to express themselves but from a general unwillingness of Americans to learn the language of a people whose products they crave insatiably. I'm mellower now, but Andy Rooney hasn't changed. 

China, India, and 9/11 have placed American concerns about Japan on the back burner, but in 1990 I reviewed The Fifth Generation Fallacy, a book about the difficulties of processing Japanese characters using computers. Moore's law has made that problem vanish too. Language processing that seemed out of reach in 1990 is commonplace today.

I began to focus on globalization in 2005 with the publication of Tom Friedman's The World Is Flat. Since then I have reviewed several more books on the subject. My Job Went to India by Chad Fowler, which I reviewed in my Jan/Feb 2006 column looks at how individual workers can remain valuable to employers. In my Jan/Feb 2007 column, I reviewed Joseph Stiglitz's Making Globalization Work, which authoritatively identifies the essential problems of globalization and shows how to solve them.

Windows and Its Challengers

In the early days of my column, the software I reviewed, like my consulting business, was largely based on the Apple Macintosh. Microsoft Windows 3.1 tipped the balance in the early 1990s, and by the time Windows 95 came on the scene, most of the books and software I saw were PC-related.

My 1995 columns are full of books about the Internet and browsers. My favorite is Lamont Wood's The Net After Dark, which focuses on the fun side of the Internet. Netscape and the World Wide Web nearly derailed the PC train, but Microsoft took decisive action to avert the Netscape challenge. Courts later found some of that action to have been illegal, but it had the desired effect. In my Jan/Feb 1996 column I reviewed Bill Gates's The Road Ahead, in which he asserts Microsoft's intention to dominate the information superhighway. 

With Netscape subdued, another challenge to Microsoft arose. I devoted my May/Jun 1996 column to Java, which, with the advent of application servers, resulted in a platform to rival Windows. At the time, I contrasted Java with C++ and predicted that the Java and Microsoft lines would look more and more alike as time went on. Java has done very well since 1996, and Microsoft has moved strongly in the same direction with .NET. I have reviewed many books on Java and .NET, but my favorite is Josh Bloch's Effective Java, which I reviewed in my Jul/Aug 2002 column. I met Bloch at JavaOne in 2006, and he told me that sales of his book increased sharply after my review. I suspect that's just a coincidence, but I'm glad the book is doing well. It's essential reading for anybody who develops Java-based systems.

Of course, Microsoft's first important battle was the original DOS vs CP/M affair. In my Mar/Apr 2005 column I reviewed Harold Evans book They Made America -- From the Steam Engine to the Search Engine: Two Centuries of Innovation. The book is a collection of short essays about innovators and innovation. The one that drew me to the book describes the way Bill Gates outmaneuvered the brilliant, talented, idealistic Gary Kildall to freeze CP/M out of the IBM PC picture.

Programmers and Their Tools

Another major theme of my columns has been computer programming. I have looked at tools like the Brief editor, Visual SlickEdit, True Basic, the Microsoft and Borland IDEs for C++, the MKS Toolkit, UML, design patterns, the open source movement, Perl, Ruby, regular expressions, and Rails. I have reviewed books like Debugging, Code Complete, The Pragmatic Programmer, Literate Programming, The Cathedral and the Bazaar, Programming Pearls, and The Practice of Programming. 

Several publishers produce excellent books for programmers, but the undisputed leader is O'Reilly. In my Jul/Aug 1989 column, I reviewed Managing Projects with Make by Steve Talbott, one of the Unix in a Nutshell series. I have reviewed dozens of O'Reilly books since then, but my most recent favorites are the Head First series. My thirteen year old daughter is learning to program using Head First Java by Sierra and Bates. The depth of her understanding of the topics she has read about astonishes me.

In my Nov/Dec 1999 column, I reviewed Kent Beck's Extreme Programming Explained, the first of many books about that phenomenon. Extreme programming is part of a larger topic called agile programming. These methodologies try to strip away a lot of bureaucratic overhead. They follow a simple pattern of asking customers for requirements in small bites called use cases, then quickly implementing bits of software that satisfy the use cases. Agile techniques work well for small projects, but many large firms are finding ways to apply them to parts of large projects. 

The theme of programming is close to the themes of usability, interaction design, and project management, all of which have appeared many times in my columns. 

Usability and Interaction Design

In my Jan/Feb 1993 column I reviewed the second edition of Paul Heckel's The Elements of Friendly Software Design. My old friend, the late Rudolph Langer, then editor-in-chief of Sybex, was very fond of this book, which had gone out of print. He encouraged Heckel to republish it with Sybex. I'm not aware of a more recent edition, but the book's principles go beyond the details of particular software packages. I haven't seen another book that looks at interface design quite the way this one does. It is still worth reading today.   

In my May/Jun 1992 column I reviewed Tog on Interface by Apple Computer's human interface evangelist, Bruce "Tog" Tognazzini. Tog applied the Jungian I-E and N-S axes (popularized by Isabel Meyers-Briggs) to interface design. He pointed out that a small cadre of IN designers are creating interfaces for the great multitude of ES users. In The Humane Interface by Jef Raskin and The Inmates Are Running the Asylum by Alan Cooper, both of which I reviewed in 2000, the authors make the same point in different ways. Several years later, Cooper followed his observations with a detailed explanation of how to perform interaction design. It appears in his book About Face 2.0, which I reviewed in my May/Jun 2006 column.

Even more detailed and academic books on usability are User and Task Analysis for Interface Design by Hackos and Redish (Micro Review Mar/Apr 1998), Dynamics in Document Design by Karen Schriver (Micro Review Jul/Aug 1999), and the imposing Contextual Design by Hugh Beyer and Karen Holtzblatt, (Micro Review Jan/Feb 2001). 

Project Management

More than thirty years ago, long before I was a columnist, I read Gerald Weinberg's The Psychology of Computer Programming, where many ideas we take for granted today first appeared as startling innovations. For example, Weinberg is responsible for the concepts of egoless programming and code walkthroughs. Nowadays Weinberg frequently teams up with the wonderful small publisher Dorset House to produce pithy books on technical leadership. He has become a guru in this area, so that many Dorset books by other authors have the Weinberg look and feel. One of my favorites is Waltzing With Bears: Managing Risk on Software Projects by Tom DeMarco and Timothy Lister, which I reviewed in my Jul/Aug 2003 column. Failure to manage risks is one of the biggest reasons that software projects cost more and deliver less than their planners imagined that they would.

Another excellent Dorset book is Project Retrospectives: A Handbook for Team Reviews by Norman R Kerth, which I reviewed in my May/Jun 2001 column. Disdaining the usual 2-hour project post-mortem held in a conference room, Kerth suggests spending a few days at a resort (or at least off-site). The idea is to let people feel safe enough to speak their minds and then provide enough time to explore the issues that arise.

Yet another wonderful book about managing software projects is Tom DeMarco's Deadline: A Novel About Project Management, which I reviewed in my May/Jun 2000 column. Every bad management practice that has ever been inflicted on you is in this book, and DeMarco turns them all into aphorisms.

My Favorites

In writing a regular column, I tell you about many things that will soon be unimportant. Sometimes, however, I write about something that gives me, and I hope you, a special feeling. Here, in chronological order, is a list of reviews that I look back on with special pride:

• Consciousness Explained by Daniel Dennett (Mar/Apr 1992)
  
• The Man Who Knew Infinity (about S. Ramanujan) by Robert Kanigel (Mar/Apr 1993)
  
• Code Complete by Steve McConnell (Jul/Aug 1993)
  
• Digital Mantras by Steven R Holtzman (Mar/Apr 1995)
  
• Java (May/Jun 1996)
  
• Only the Paranoid Survive by Andy Grove (Mar/Apr 1997)
  
• Darwin Among the Machines by George B Dyson (Jul/Aug 1997)
  
• Extreme Programming Explained by Kent Beck (Nov/Dec 1999)
  
• The Pragmatic Programmer: From Journeyman to Master by Hunt and Thomas (Jan/Feb 2000)
  
• Bill Joy's warning from the April 2000 Wired Magazine (Jul/Aug 2000)
  
• The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity by Alan Cooper (Sep/Oct 2000)
  
• Effective Java by Joshua Bloch (Jul/Aug 2002)
  
• Me++: The Cyborg Self and the Networked City by William Mitchell (Nov/Dec 2003)
  
• The World Is Flat: A Brief History of the Twenty-First Century by Tom Friedman (May/Jun 2005)
  
• The Singularity is Near: When Humans Transcend Biology by Ray Kurzweil (Jan/Feb 2006)