XRM Content

Technology

2011-04-01T15:59:00.000-07:00

This time I look at two books that delve deeply into technology and our relationship to it. One, by Brian Arthur, is concerned with how technology works and how it interacts with economics. The other, by Kevin Kelly, tells a poetic, almost mythic story of where technology came from and where it's headed. Their stories overlap and reinforce one another. I highly recommend both of them.

The Nature of Technology: What It Is and How It Evolves by W. Brian Arthur (Free Press, New York, 2009, 256pp, ISBN 978-1-4165-4405-0, $27.00)

Brian Arthur is an influential theorist of economics and complexity theory. His work has influenced many Silicon Valley entrepreneurs. He is a member of the research faculty of the Santa Fe Institute and a visiting researcher at the Palo Alto Research Center (PARC). This book grew out of lecture series Arthur gave in 1998 and 2000.

Arthur sets out to investigate, from an economist's point of view, what technology is and how it evolves. He observes that we use the word "technology" with three distinct meanings:

A means to fulfill a human purpose (for example, an iPhone or a legal system).
An assemblage of practices and components (for example, the semiconductor industry).
The entire body of devices and practices (what Kevin Kelly calls the technium).

For the first of these, Arthur uses the term purposed systems, reserving the term technology for systems (for example, the iPhone) that capture and exploit physical phenomena. A legal system shares many of the characteristics of a technology, but the phenomena it exploits are social and behavioral.

Arthur uses the term domain for an assemblage of practices and components. Domains are toolboxes. They form a language of rules and practices that define the possible technologies that can develop within that domain. Domain change is a major force in technological advance. For example, in the 1970s, aircraft designers moved from the mechanical and hydraulic domains to the electronics domain for controlling wing and stabilizer surfaces. Domains can have vast supporting structures, so a complete domain change can take decades and cause economic dislocation.

Arthur calls on the principles of combination, recursion, and phenomena to find a common structure for all technologies. A technology exploits one or more natural phenomena. The technology's internal structure is a main assembly that carries out its base function and a set of subassemblies that support the function. Each subassembly is a technology with the same overall structure. It isn't turtles all the way down -- the recursion is finite -- but most technologies have many levels.

This modularity makes it easy to see one of the main ways technologies advance and develop. Substituting a new subassembly for an old one can solve a problem or bring an improvement: lower cost, better performance, more functionality, suitability for more environments, and so on. For example, in the 1920s, aircraft designers wanted to achieve greater speed by flying higher, but they needed to invent the turbojet engine to make that possible. They were able to replace the engine subassembly while leaving many other subassemblies intact, at least at first.

This is a high level view, but Arthur gives a detailed picture of how standard engineering works to exploit and reinforce this model. In so doing he shows that the evolution of technologies does not follow a Darwinian model. Swapping one subassembly for another rarely happens in the biological domain. Darwin relies on long sequences of small steps and survival of the fittest.

In engineering, many factors besides fitness determine choices. For example, early nuclear reactors used light water for both the coolant and the moderator. This was not necessarily the best approach. The US Atomic Energy Commission made the decision for reasons largely irrelevant to fitness, but once it had a foothold, this design became the standard.

Arthur examines the mechanisms of technological revolutions. A new domain arises from an existing one. Perhaps an investment mania and a crash follow, but the new domain grows well beyond pre-crash levels. The economy follows as existing structures adapt and re-architect themselves over the course of decades. Change is expensive, and often the necessary changes are not obvious. The switch from steam-powered factories to electric ones required a total redesign, but factory designers did not grasp the needs and possibilities of the new technology.

The leading edge tends to be concentrated in one region. Silicon Valley is a prime example, but there are many others. A virtuous cycle emphasizes the region's initial advantage. Practitioners are drawn there. Informal networking spreads undocumented knowledge and provides unofficial channels for solving problems. This mechanism explains why Akron, Ohio, was able to turn itself into Polymer Valley when the tire industry moved away.

Arthur has advice for politicians and entrepreneurs who are concerned about competitiveness: build basic science without a stated purpose of commercial use. Encourage and remove obstacles from the small startups that naturally develop. Creating a leading edge region requires gardening, not central planning. Water it, weed it, and let it grow.

Arthur's model of the ongoing evolution of technology is as follows. A long history of technology has left us with an active set of technological components. A new technology enters the active set and becomes available to replace subassemblies of existing technologies and may enable additional technologies. The economy adjusts. The new technology creates new problems and opportunities. A domain may grow up around it. The process repeats many times, often in parallel. Like a coral reef, technology is a living thing. It has needs and a kind of autonomy, but so far it still requires human intermediaries.

Like many other writers, Arthur sees our relationship with technology as ambivalent. Our deepest hope lies in technology, but our deepest trust is in nature. We need challenge, meaning, purpose, and alignment with nature. Technology can help us meet those needs or thwart us by subjugating us to its purposes. Like good and evil, these aspects of technology are part of our world, and we must constantly engage them. We should not accept technology that deadens us, and we should not confuse what's possible with what's desirable.

Brian Arthur has produced a thoughtful and coherent account of how technology evolves. He has deliberately done so using plain language to make it available to a large audience. If technology plays a significant role in your livelihood, you should read this book.

What Technology Wants by Kevin Kelly (Viking, New York, 2010, 416pp, ISBN 978-0-670-02215-1, $27.95)

Kevin Kelly was editor-in-chief and publisher of Whole Earth Review. He had roles in launching The WELL and the Hacker's Conference. He later became Wired 's first executive editor. He is on the board of the Long Now Foundation. He co-hosts a monthly seminar series with Stewart Brand.

Kelly spent his early years as a freelance photographer, wandering around Asia with very little technology: clothing, a sleeping bag, a pen knife, and his cameras. After a religious experience in 1979 (which he described on NPR's This American Life in 1997), he resolved to act as if he had only six months to live. He gave away his money anonymously and bicycled 5000 miles around the USA to visit his relatives. Along the way he encountered the Amish, and admired their contentment.

When the six months passed and he found himself still alive, he began his new life with a unique perspective. He discovered online communities and came to see a benefit of technology that strongly influences a thesis he presents in this book, namely, that technology increases opportunities for people to realize their potential. What would Mozart, Van Gogh, or Hitchcock have been if they had lived before the piano, cheap oil paints, or film?

Kelly admires the Amish relationship to technology. An Amish community is selective about what it embraces. They try new technologies, then use known criteria to arrive at a communal evaluation and decision. Kelly embraces a similar approach in his own life. He strives to increase his personal contentment by minimizing the technology in his life. At the same time he wishes to maximize the contentment of others. This requires embracing and helping technology's growth.

To understand how he should relate to technology, Kelly looked at it from many angles, finally arriving at a grand view of an epic battle between entropy and exotropy (anti-entropy). From the undifferentiated starting point of the big bang, exotropy rapidly outpaced entropy in a continuing act of self-creation and self-organization that led to galaxies, planets, life, minds, language, and beyond. Exotropy pushes toward ever more abstract and immaterial expressions. Brains and language are important steps along the path.

At our current stage, billions of years into the process, humans have significant influence on the direction of technology's evolution, but Kelly does not see that as as an eternal truth. He sees the body of technology, which he calls the technium, as exhibiting many characteristics of an autonomous living thing. The book's title reflects this point of view. But Kelly chooses a surprising spokesman to articulate it.

Ted Kaczynski, aka the Unabomber, sees technology as increasingly restricting freedom because it strengthens society and imposes its own needs as well. Kaczynski supports an ideal of nearly complete freedom, only admitting a few rules necessary to make basic human interactions possible. Unfortunately, these rules allow mailing bombs to people you disapprove of.

Kelly cites the Unabomber Manifesto because it is an extreme representative of the opposite of what Kelly believes. When it comes to the same conclusions Kelly does about aspects of the technium, it strengthens Kelly's confidence in those conclusions. Kelly and Kaczynski both believe that the technium pursues its own needs with a kind of autonomy. Both also believe that the technium creates serious problems.

Kaczynski believes that the technium does more harm than good, and that compounding that differential over time will lead to its destruction. Because humans are increasingly dependent on complex technologies that they no longer understand, they will perish too.

Kelly believes that the technium does more good than harm. Compounding that differential over time leads to greater happiness and opportunity for humanity and to ever better ways for things to improve. Each of these men is expressing a judgment about the balance between the good and the harm that the technium does. Kelly adduces many examples to support his conclusion. For example, the long term trends toward greater longevity, health, and wealth suggest that the compounding factors are positive.

If you accept that the technium has a sort of autonomy, then it makes sense to ask what it wants. Kelly believes that technology wants what life wants. The summary, which Kelly develops with many examples and much discussion, is that technology wants increasing efficiency, opportunity, emergence, complexity, diversity, specialization, ubiquity, freedom, mutualism, beauty, sentience, structure, and evolvability. These terms define the trajectory and mechanisms that the technium has followed from the big bang to today and seems likely to follow into the future. Kelly says, "a single thread of self-generation ties the cosmos, the bios, and the technos into one creation."

At this point you might feel that Kelly has devised a creation story for an age that feels uncomfortable with the traditional ones. Kelly is quick to say that the technium is too small to be God. But he speculates that we may see a new Axial Age spurred by technology. He says,

I find it hard to believe that we could manufacture robots that actually worked and not have them disturb our ideas of religion and God. Someday we will make other minds, and they will surprise us. They will think of things we never could have imagined, and if we give these minds their full embodiment, they will call themselves children of God, and what will we say? When we alter the genetics in our veins, will this not reroute our sense of a soul? Can we cross over into the quantum realm, where one bit of matter can be in two places at once, and not believe in angels?

In this new Axial Age, Kelly believes, we may seek spiritual refuge not just in ancient redwood groves, but also in ancient networks.

This review might not convey the excitement I felt while reading Kelly's book. The book is too dense to summarize easily here. The language is poetic, but hard to paraphrase, and many of the most interesting points are hard to lift from their complex contexts. I spent months digesting this book, and I enjoyed doing so. I hope you'll do the same.

Being Geek

2010-11-01T21:53:00.000-07:00

This time I look at a book that is remarkable for its author's exceptional insights and uncommon points of view.

Being Geek: The Software Developer's Career Handbook by Michael Lopp (O'Reilly, Sebastopol CA, 2010, 334pp, ISBN 978-0-596-15540-7, www.oreilly.com, $24.99)

Michael Lopp has worked in Silicon Valley for more than 15 years. He is an engineering manager at Palantir and has worked for ground-breaking companies like Netscape, Apple, Borland, and Symantec. He was also part of a failed startup. He is the author of Managing Humans and the Rands in Repose blog. Being Geek draws heavily on postings from that blog.

Geeks

Lopp's target audience consists of software developers and people like them. He calls them nerds or geeks interchangeably. He chose the word geek for this book because he liked the sound of the resulting title.

If you're one of Lopp's geeks, you're socially handicapped in ways that he describes in a chapter called The Nerd Handbook, a guide to give to your friends and family. Your sense of humor grows out of your bitterness over your early life as an outcast. You have a project, and it's always on your mind. Your relevance detector tunes out small talk, making it difficult for you to relate to others. You are a systems thinker. Your model of the world is a computer. If you know the rules, you can figure out what to do next. Ambiguity makes you anxious.

Unlike many software developers, Lopp has no difficulty interpreting the non-verbal aspects of his surroundings. He observes the behavior of colleagues and generalizes the lessons he learns. He picks up on the unspoken cues in situations, so developments rarely take him by surprise. Following some of Lopp's advice, however, may require more facility at interpreting the non-verbal than many potential readers have.

Rules of three

Lopp thinks strategically, so he can react to unpleasant surprises by remembering the big picture. He may have a manager in his job, but Lopp is the manager of his own career. His two-pronged approach to this book is as follows:

Teach you a system of improvisation so that you can navigate the day-to-day unpredictability of the work world.
Help you develop a strategic career plan, so you know what to do if the sky falls in your current job.

To teach you a system of improvisation, Lopp takes you through the kinds of situations that are likely to arise in software development firms and helps you understand the underlying system and rules. He shows you tools and techniques for managing your time and workload.

To help you develop a strategic plan, Lopp provides a narrative—a single job in all its aspects, from interviewing to leaving, seen largely from the perspective of a manager. He likes the number three, so he gives you three questions and asks you to keep them in mind as you follow the book's narrative:

What am I doing?
What do I do?
What do I care about?

To Lopp, your day-to-day work, your management philosophy, and your career plan should be driven by another set of three questions:

Am I setting the technical direction?
Do I know what I have to do to grow?
Am I keeping my commitments?

Lopp uses technical direction as a shorthand for all of the technical aspects of your career, from choosing an area to work in to writing a piece of code. You might not get to make all of the decisions, but if you write code, you should know what’s best for it at all stages of its life.

Failure to grow brings quick death in the technical world. Information has a short half life. If you haven’t failed recently, if nobody is challenging you, if you haven’t learned anything significant this week, you are in danger of falling behind.

Failing to keep a commitment, even a minor one, puts a scar on your reputation that is hard to erase. Your reputation is a huge asset that you should maintain at all costs. Sometimes this means telling your boss that you can’t handle that one extra task. Better to say no than to say yes and not do it.

There, in a nutshell, is Lopp's philosophy. But the best thing about the book is Lopp's insight into situations, management techniques, and tools. The bulk of the book explores all aspects of a hypothetical job.

Job hunting

Lopp starts with the decision to leave your current job. After three years in a job—three releases for the product to become real—you might start to feel the itch to leave. Don’t mistake anger for the itch—cool off first before you act. When you do feel the itch, however, it’s time to go. You might have reservations about whether you’re really done or about the people you’re leaving behind, but Lopp has good answers to those reservations. You’re never really done, and your network transcends individual companies. Start looking for your next challenge.

Many books contain advice about resumes, portfolios, and interviews. This one is as good as any. Most of it is in line with other books, but Lopp addresses one area I haven't seen elsewhere. As an interviewee, you want to help the interviewers get what they need, but you need to elicit information too. Lopp talks about finding the "button" that will get each kind of interviewer talking. Some interviewers arrive angry, some love to talk, some try to maintain control, but for most of them, there is a strategy that will loosen their tongues.

Lopp also looks at some of the dangers that can catch a hiring manager napping. Requisitions look good on paper, but they can disappear in an instant. He recommends spending at least an hour a day on each open requisition. He also advises laying some groundwork before you have a requisition. Build a network of people you can call when the requisition appears.

Sometimes someone you thought you had hired decides to stay where they are. Lopp believes that this is often because you didn’t let them know how much you want them. He advises keeping in touch from the day they accept the offer until the day they show up for work.

People on the job

Lopp emphasizes the kinds of informal interactions and relationships that don't show up on the organizational chart. When he was at Netscape, for example, four people who didn't look especially important on the organizational chart met each day to play bridge. He soon learned that they set much of the technical direction and corporate culture. When one of them left the company, long before the visible signs of trouble, Lopp knew that it was time to go.

Another interesting bit of analysis that Lopp performs concerns what happens when you make a big mistake. Your boss temporarily assumes a new persona: Interrogator, Illuminator, Randomizer, Prioritizer, or worst of all, Enemy. The temporary change may reveal attitudes and communication problems you didn't know existed. Lopp characterizes each of these reactions and shows how to restore your boss's usual calm, supportive personality.

Lopp brings his insights to other common situations. Your group gets sudden bad news and a number of personas appear, some requiring careful treatment. One displays explosive anger. Another refuses to accept the news. Yet another sees the sky falling. One blames himself while another says, "I quit." Lopp shows the course that each of these reactions is likely to take and explains how to get everyone into problem-solving mode.

Interpersonal relations take work, but some people are too much work. Every group has its values and beliefs. Those who are fundamentally incompatible with those values and beliefs must go, no matter how good they are. As Lopp puts it, the history of Silicon Valley is full of toxic people who were right. Their agenda and ideas were right for their company. Nonetheless, they had to go.

Lopp believes in the Pond. The workplace supports many information flows—official and unofficial. If you're there, you pick up on them. If you're not, you don't. When someone on his team wants to work remotely, Lopp may feel he has to say yes, but he worries. Stepping out of the Pond may be that person's first step toward leaving. On the other hand, the modern world makes it difficult to avoid remote workers altogether. Lopp identifies the factors in the employee and in the group that are essential to making it work.

Games

Lopp has two important roles for games in his management approach: stimulating activity and developing relationships. In one example, he uses a list of bugs on a whiteboard and a system of scoring for analyzing and fixing them. Players use different colors to record what they do, and everyone can see who is accumulating points.

Back Alley Bridge, known by its acronym, BAB, has been around for at least fifty years. It looks a bit like Bridge and a bit like Hearts. The bidding is a bit like Pinochle. An important aspect is the trash talk that accompanies play. Lopp uses it to build trust between two managers who aren't getting along.

The Werewolf game has made the rounds of the Internet in various forms. Each night in the village, the werewolves kill someone. Then the remaining players awake and try to identify a werewolf to kill. They have nothing to go on but what they observe, as one after another is accused and presents a defense. Lopp believes that playing this game will sharpen your interpersonal skills and prepare you for business meetings.

Networking

When people talk about networking, they usually mean building a network of contacts throughout the industry. Lopp has a slightly different emphasis. He tells you to find "your people." Growing up, you may have been an isolated one in a thousand. But now you can improve your odds considerably. Go to conferences. Join affinity groups. Contribute to mailing lists. You will know your people when you see them. Writing about what you care about can be your initial connection, but extended face-to-face interactions show you what email hides: I talk with my hands. You can't stand the distraction of looking anyone in the eye when you're thinking hard.

Managing time

Lopp has a lightweight system for tracking the tasks he should be working on. His artifacts are a to-do list, a parking lot list, and a trickle list. He reviews them briefly twice per day—the morning scrub and the evening scrub. His underlying principles: you won't complete everything you should; if you drop an important task, it will find its way back.

The morning scrub starts with yesterday's to-do list. If you intend to do an item today, leave it on. Don't assign it a priority or a completion date. If you intend to do it after today, use it to start today's parking lot. If you don't have a realistic plan for doing it soon, throw it away. The evening scrub is similar.

The trickle list tracks long-term goals. The column heads are types of activities, like read a book or have a hallway conversation. Each day gets a row of Xs and Os. Looking at the list can remind you of things you need to do or changes you need to make to your long term priorities.

Lopp has a framework for deciding which tasks to take on. Some things that come his way are crises. He has to take them on. In addition, he insists on devoting some time to creative activities—sitting in a room and thinking or doodling on the whiteboard. He hopes to delegate everything that falls between—routine matters—to someone else.

Bits, features, truth

Everyone talks about the triangle of time, quality, and features. You can have any two of the three. If you think about this metaphor for any length of time, it falls apart. Lopp replaces it with the idea that on any project there should be three separate authorities, one each for bits, features, and truth. These are the traditional roles of the engineering manager, the product manager, and the program manager, but thinking in terms of the actual functions may be more realistic.

The people occupying the three roles should be equally strong. There should be both a healthy tension and mutual respect between any two roles.

A complaint

My main complaint is about editing. The credits list an editor, a production editor, a copyeditor, and a proofreader. Nonetheless, the book has many typographical errors. The writing style is far from crisp. Furthermore, I feel that it suffers from a serious error of editorial judgment. The writing is full of unnecessary profanity. Even if the author speaks that way, there is no need to reproduce the vulgarities in print. They add nothing essential.

I recommend this book highly because of its content. This review covers many aspects of the book, but there are important topics I don't mention. If you have anything to do with software development, or if you just feel geeky, I hope you'll buy the book and study it.

Miscellany

2010-08-01T14:49:00.000-07:00

This article appears in slightly different form in the July/August 2010

My backlog of books to review has grown out of hand. I don't have time or space to do justice to all of them. So here are some interesting books with brief explanations of why I hope you'll find reading them worthwhile. I recommend all of them.

Math and philosophy

Recently I've read two books co-authored by Ellen Kaplan. She wrote one with her husband Robert and one with her son Michael. Both books are simultaneously erudite and readable, with delightful allusions to many aspects of culture. The books deal with some of the philosophical and technical underpinnings of the modern world.

Another math book, by a physicist, focuses on how to solve thorny problems using heuristic techniques, approximations, and lucky guesses.

The Art of the Infinite by Robert Kaplan and Ellen Kaplan (Oxford University Press, Oxford, 2003, 334pp, ISBN 978-0-19-517606-3, www.oup.com, paper, $16.95)

In 1994 Robert and Ellen Kaplan founded The Math Circle (www.themathcircle.org), a school "designed for students who enjoy math and want the added challenge of exciting topics that are normally outside the school curriculum." In this book they introduce us to numbers, plane geometry, and some of the mathematicians who have furthered the study of these subjects. Because some of the deepest results of mathematics arise from considering the infinite, the authors try to ensure that we understand the definitions and philosophical underpinnings of that concept.

Georg Cantor's proof that the infinity of real numbers is greater than the infinity of whole numbers is well known and easy to understand. The authors show us the painful years-long path Cantor followed to arrive at that insight. This kind of humanization of mathematicians is one of the book's strengths. The intuitionists and the formalists, like Swift's big-endians and little-endians, both turn out to have the same sorts of foibles as the rest of us.

Chances Are: Adventures in Probability by Michael Kaplan and Ellen Kaplan (Viking, NY, 2007, 332pp, ISBN 978-0-1430-3834-4, www.penguin.com, $26.95)

The dust jacket of this book bears a photograph, taken by Robert Kaplan in 1961, showing Ellen Kaplan pushing Michael Kaplan in a stroller. Subsequently, Michael studied European history at Harvard and Oxford. He is now a writer and film maker. Ellen is a classical archaeologist. She has taught math, biology, Greek, Latin, and history. Neither author is a professional mathematician. Perhaps their backgrounds explain their ability to see the big picture.

Probability and statistics have infiltrated practically every important aspect of our lives. It began simply enough when gamblers sought help from mathematicians like Fermat and Pascal. The resulting mathematics soon helped sea traders hedge against the unpredictable risks their ships faced with each voyage. The insurance industry expanded to cover other commercial and personal uncertainties.

Insurance and medicine have become entwined. While death panels may be a fantasy, medical practice and reasoning are firmly grounded in probability. In 1976 I wrote a review of Galen & Gambino's Beyond Normality: The Predictive Value and Efficiency of Medical Diagnoses (Wiley, 1975). Their work explained how to apply Bayes' theorem to evaluate the value of diagnostic testing. At the time most physicians were only beginning to understand this type of reasoning. Now it controls much of what they do.

Legal reasoning is another area where thinking about probability can be useful. It does, however, sometimes lead to highly unintuitive results. This has led appeals courts to reject expert testimony based on Bayes' theorem. According to the authors, "the technique has been forbidden, not because it doesn't work, but because the court may not understand it. We can continue to err, as long as we err in ways we find familiar."

Game theory and military planning underlie decisions that affect our very existence. In fact, the Cold War came to a peaceful end largely because leaders cast aside the "best" strategies in favor of a more humane view of human behavior.

I don't think you can understand today's world without understanding the concepts in this book. The authors have put it all in one place for you. Get it and read it.

Street-Fighting Mathematics: The Art of Educated Guessing and Opportunistic Problem Solving by Sanjoy Mahajan (MIT, Cambridge MA, 2010, 150pp, ISBN 978-0-262-51429-3, mitpress.mit.edu, 25.00)

Sanjoy Mahajan, a physicist, is the associate director for teaching initiatives at the MIT Teaching and Learning Laboratory (TLL). The TLL works with faculty, teaching assistants, and students to promote excellence in teaching and learning.

Carver Mead, one of Mahajan's thesis advisors at Cal Tech, says in the foreword to this book

Most of us took mathematics courses from mathematicians -- Bad Idea! Mathematicians see mathematics as an area of study in its own right. The rest of us use mathematics as a precise language for expressing relationships between quantities in the real world, and as a tool for deriving quantitative conclusions from those relationships.

So if you want the answer, or something close to the answer, and you don't care about the proof, the techniques in this book might be just what you're looking for.

Mahajan considers his work to follow the path of the great mathematics teacher George Polya. Polya cited Euler and Laplace as mathematicians who perceived that "the role of inductive evidence in mathematical investigation is similar to its role in physical research." Some of the techniques that Mahajan describes are similar to the ones Euler used to find the sums of infinite series in the 1700s.

While the ideas Mahajan puts forth are relatively simple, many of his examples would be difficult to follow for someone without at least the prerequisites for an MIT education. If you have those prerequisites, you might enjoy reading this book.

Grammar, usage, and editing

Ambrose Bierce's Write It Right: The Celebrated Cynic's Language Peeves Deciphered, Appraised, and Annotated for 21st-Century Readers by Jan Freeman (Walker, NY, 2009, 236pp, ISBN 978-0-8027-1768-9, www.walkerbooks.com, $24.00)

Just over a hundred years ago, Ambrose Bierce, a journalist better known for his cynical Devil's Dictionary, wrote Write It Right, a quirky collection of prescriptions for writers. Recently, Jan Freeman, who writes a language column for the Boston Globe, decided to examine Bierce's maxims. She apparently decided to do so for an indirect reason. Bierce's fiercely expressed complaints are largely irrelevant today. They have been replaced by new pet peeves. By showing the irrelevance of most of Bierce's complaints, she helps us gain perspective on our own hobgoblins. They may be just as quaint a hundred years from now as Bierce's are today.

Bierce, like many language purists today, based many of his rules on a belief that English should be logical. But many of the illogical usages he complained about had been established hundreds of years before, and many persist today. Freeman makes this clear again and again as she carefully analyzes all 441 of Bierce's rules. If you're interested in usage issues, you'll enjoy this book.

Making Word Work for You: An Editor's Introduction to the Tool of the Trade by Hilary Powers (Editorial Freelancers Association, NY, 2009, 80pp, ISBN 978-1-880407-22-6, www.the-efa.org, spiral, $15.25)

Now in her fourth career, Hilary Powers has been a freelance editor since 1994. She says she chose editing to enable her to emulate Nero Wolfe, that is, never to have to leave home on business. Before her first year as an editor was done, she had abandoned paper. She works only online, a fact that has necessitated her mastery of Microsoft Word.

The target audience of this small, spiral-bound book is anyone who edits for a living. Anyone who uses Word, however, will find useful information in it. For example, editors must master Word's change-tracking facilities, but many non-editors use that feature too. Macro programming is another powerful feature of Word that will quickly repay your learning how to use it well. Powers shows you where and how to use macros and provides free downloads of her own macros to help you learn the details.

Whether the task is mastering macros or simply selecting configuration options, this book removes your excuse for avoiding it. If you're like most Word users, you could do a lot of what this book recommends without reading it. Once you have this book, however, and read about the huge increases in efficiency that Powers achieves, you won't be able to resist the urge to tinker.

I have known Hilary Powers for many years, so I can testify that she writes the way she speaks. Her style is clear and colorful, never boring. The topics she covers are practical and directly useful. If you use Word, you should read this book.

Communicating

Confessions of a Public Speaker by Scott Berkun (O'Reilly, Sebastopol CA, 2010, 240pp, ISBN 978-0-596-80199-1, www.oreilly.com, $24.99)

Scott Berkun is a technical author who decided to try to make a living as a public speaker. He succeeded, and this book tells how he did it and what he learned along the way. None of it is glamorous -- even his being interviewed with prominent business leaders by Maria Bartiromo on CNBC. Berkun shows you the tricks of the trade -- the drab details and shameless gimmicks that help ensure that your audience goes away happy.

One of the parts I like best is "The Clutch Is Your Friend." This chapter title comes from something Berkun's brother told him to help him learn to drive a car with a manual transmission. It introduces some excellent rules about how to teach -- whether you're facing one person or 5000.

Berkun says, "Everything in this book is true and written to be useful, but if you don't always want to hear the truth, this book might not be for you." By this he means that after seeing how sausage is made, you might never want to eat it again. That hasn't been my experience. I find the material fascinating. If you ever speak in public, you'll learn something useful from this book.

The Back of the Napkin: Solving Problems and Selling Ideas with Pictures, expanded edition, by Dan Roam (Penguin, NY, 2009, 300pp, ISBN 978-1-59184-306-1, www.penguin.com, $28.95)

Dan Roam designs presentations and gives seminars about visual thinking. Here is his elevator pitch for this book:

"Visual thinking means taking advantage of our innate ability to see -- both with our eyes and with our mind's eye -- in order to discover ideas that are otherwise invisible, develop those ideas quickly and intuitively, and then share those ideas with other people in a way they simply 'get.'"

Those of us who communicate for a living know that visual communication is an important tool, but few of us feel comfortable using that tool. The biggest obstacle that Roam must overcome is I can't draw. He allays that concern in this book by using simple drawings made from rough hand-sketched elements. Nobody draws worse than I do, but I can replicate any of the drawings in this book -- at least well enough to communicate effectively.

In planning how to explore or express an idea visually, Roam asks five questions about what he wants his drawing to emphasize:

* Simple or elaborate?

* Qualitative or quantitative?

* Vision or execution?

* Individual or comparison?

* Change (delta) or status quo?

This gives him the colorful mnemonic SQUID, for which he provides a minimal but recognizably squidlike sketch.

Roam applies the SQUID questions in each of his main areas: discovering, developing, and selling ideas. On this framework he hangs profusely illustrated examples. All you have to do is read along with pencil and paper at hand, and you'll learn that you really can use visual thinking effectively.

Conversation and Community: The Social Web for Documentation by Anne Gentle (XML Press, Fort Collins CO, 2009, 236pp, ISBN 978-0-9822191-1-9, xmlpress.net, paper, $29.95)

Anne Gentle is a technical writer who ran a company blog in the prehistoric days of that technology (2005). She learned about using wikis for documentation by volunteering for the One Laptop per Child project. She also works with FLOSS Manuals, a community that supports tools for producing free documentation for free software.

Gentle sees a structural shift from one-way product documentation toward interactive, collaborative product support that includes plenty of user-generated content. Technical communicators steeped in the old model need help understanding and moving to the new one. This book provides such a guide. Gentle proceeds methodically through the new technologies and discusses the issues that arise for communicators.

If you have a role in technical product documentation, you should read this book.

Search Patterns

2010-03-21T01:27:00.000-07:00

This article appears in slightly different form in the March/April 2010

Designing for Discovery

Asking questions and wanting to know the answers is basic to human nature. No one knows of a time when this was not so. Researchers have speculated that human culture took a great leap forward when life expectancies increased to the point that children could interact with their grandparents. Word of mouth sufficed for a long time, but writing and printing led to further leaps forward.

It is a commonplace observation that sources of data are now increasing exponentially and that old methods of transmitting knowledge cannot keep up. Search technology has arisen to address this problem, but how best to use that technology remains an unsolved problem. Most computer users know how to go to Google or other search engines, enter search terms, and browse through results. Few user interface designers, however, know how to incorporate effective search technology into their designs. The book I look at this time addresses that problem.

Search Patterns: Design for Discovery by Peter Morville and Jeffery Callender (O'Reilly, Sebastopol CA, 2010, 192pp, ISBN 978-0-596-80227-1 www.oreilly.com, $39.99)

Peter Morville is a founder of the field of information architecture. He is author of "Information Architecture for the World Wide Web" and "Ambient Findability." His consulting clients include AT&T, Harvard, IBM, Microsoft, and the Library of Congress. Jeffrey Callender is the design director of Q LTD, a strategic design consultantly with clients worldwide. Peter bills himself as the word person. Jeff is the visual thinker. Their collaboration successfully integrates these ways of thinking.

Search, say the authors, is the worst usability problem on the web. We go to a website to find something -- a fact, a product, background information, an old acquaintance. Often, what we thought we came for is not actually what we need. Search is a conversation in which we discover new things and ask new questions. How quickly and accurately we find what we need defines the quality of our experience. If we give up and revert to more costly options like telephone or email, everyone loses. Yet that is what often happens when companies fail to use search technology effectively.

Patterns and interconnections

Apophenia, an aspect of madness and creativity, is the ability to see connections that others don't see. The savant Daniel Tammet sees patterns of shape and color in the digits of π that allow him to recite tens of thousands of digits accurately. To those who do not perceive such patterns, the feat seems impossible.

The authors are writing for an audience of highly sophisticated user interface designers who can hold their own with engineers and marketers and make the business case with upper management for investment in search technology. The authors' goal is to discover and study the patterns of search so that these designers can make search better.

The study of software design patterns owes its basic idea to Christopher Alexander, who wanted a language to help him describe the architecture of living spaces. In A Pattern Language, he recognized that how you put the patterns together makes all the difference. He analogized this to poetry. In prose we strive for simple sentences in which each word has an unambiguous meaning. In poetry the words come from the same language, but they have multiple meanings and connotations. They are packed densely together to express what prose cannot express efficiently.

Morville and Callender see poetry as the model for using the search patterns they present as the heart of their book. But they take the poetry model further. This is a densely packed book of interconnected meanings. Its 192 pages contain more useful information than many books of three times its length, but you must read slowly and carefully to extract that information. For example, here is how the authors identify the problem that they are trying to solve:

" . . . search is a wicked problem with no definitive formulation, considerable uncertainty, and complex interdependencies. Stakeholders have divergent goals and radically different world views. Requirements are incomplete, contradictory, and ever changing . . .

"Unlike Google, most firms aren't structured to manage the high-tech, step-changing, cross-functional, user-centered challenge. There are too many hyphens. As a hybrid of engineering, marketing, and design, search creates too many openings for missing links . . . Why risk your career (and your weekends) on a problem that's so intractable?

"We underfund and understaff search, and its poverty becomes a self-fulfilling prophecy. Users don't search now, because search failed then. Sometimes they browse. Often they bail."

To help describe patterns, the authors first break down search into its static anatomy and its behavioral aspects. The major elements of search are users, creators, content, the engine, and the interface. The many relationships among these elements help explain the complexity of search and the ideas in this book. For example, a search engine may take account of users' preferences, but if users don't bother to use the available customizations, they all wind up with the same default behavior. An interface may present results effectively, but if the searched content is full of redundant, outdated, trivial (ROT) material, users will not be able to find useful results quickly. Sometimes users are creators, when they give feedback about the relevance of results or comment upon a discovered item. The well known site that puts all of the elements together most effectively is amazon.com. The authors use Amazon as a good example of many patterns, but they point out that every situation is different. The Amazon approach works well because Amazon tailored its approach to the specific characteristics of its unique business.

The static anatomy helps us understand the elements of search, but to make specific situations better, designers must also understand the kind of conversation that leads to discovery in their environments. To succeed, search must have aspects of jazz. The process must flow. The authors cite Mihaly Csikszentmihalyi's contention that music, dancing, sailing, and chess are conducive to flow because they offer challenge, give control, support learning, reward skill, and provide feedback.

Just as designers repeat successful design patterns, users repeat the behavioral patterns that have worked for them. Search designers must support these behavior patterns. The main ways users interact iteratively with search facilities are narrowing/expanding searches and growing pearls. The main problems (antipatterns) they encounter are pogosticking and thrashing. To grow pearls, users find a good document and mine it for query terms and leads. Google supports this by offering links to similar items. Pogosticking is bouncing back and forth between a results page and the pages it points to. Thrashing occurs when users start from a flawed query (for example, using a misspelled term), then keep trying variations of it rather than switching to a better query.

Principles and patterns

The authors are interaction designers, and because they see little evidence of interaction design principles at work in search interfaces, they feel compelled to explain those principles. You'll have to read the book for the complete story, but here is a brief summary of some interaction design principles:

Incremental construction lets users start small and build.
Progressive disclosure hides complexity until it is needed.
Direct manipulation provides visible objects for users to interact with.

The heart of the book is a discussion of ten design patterns. The choice of these specific patterns is meant as a convenient and somewhat arbitrary starting point. The authors describe each pattern, identify its most suitable contexts, and show how it relates to the other patterns. They discuss why the problem that the pattern addresses is common and why the pattern provides a good solution. They provide examples that you can visit, interact with, and study.

The Autocomplete pattern is the first and the easiest to understand. Typing is slow, especially on mobile devices. Users cannot spell, and they cannot remember search terms. As users enter the first few characters, the system begins to offer suggested search terms. This depends, of course, on having a good source of suggestions. Google does this well. Most sites do not.

The Best First pattern is deceptively simple. The system sorts results in such away that the first few results that users see are the ones most likely to be what they are looking for. A huge portion of what Google does behind the scenes supports this pattern. When implemented properly, a best first approach quickly gives users what they need or helps them formulate effective follow-up queries.

The Federated Search pattern addresses the problem of finding content that is distributed among a variety of content sources (silos). Implementing it entails problems such as slow performance and different query languages in different silos. Combining the silos into a single source may be a better approach to the problem. A good example of where to use federated search is hunting for books by author, title, subject, and so forth, across a set of independent university libraries.

The Pagination pattern emerged by accident, not as a response to a specific problem. Designers found it convenient to return a linear list of search results and to enable users to navigate through the list in screen-sized pages. Users soon discovered that pages provide a way to bookmark specific sets of results. Interfaces that replace the simple results page may have to provide a different approach to that use case.

The Faceted Navigation pattern gets away from the simple results page. It arises from the work of Marti Hearst and her Flamenco project at UC Berkeley. Using content and metadata from returned results, it constructs a custom visual map that makes it easy for users to narrow their queries incrementally. A drawback of this pattern is that it requires a large amount of screen space, so it does not work well on small mobile devices. The authors regard this pattern as the most significant search innovation of the past decade.

The Structured Results, Actionable Results, and Unified Discovery patterns all contribute to speeding discovery and making the process more iterative and interactive.

Moving search forward

Practitioners will especially appreciate the chapter called Engines of Discovery. Having laid out the principles of interaction design and created a language for discussing search patterns, the authors examine and discuss a number of sites that explore new ways to help their users discover what they may not have known they were looking for. Visiting these sites and understanding how they use search patterns is key to deriving maximum benefit from this book.

The authors hope that this book will influence the future of search technology. They see themselves not just as technologists and communicators, but as persuaders. In support of that function they have created some futuristic scenarios that they hope will serve as mythic guides for search technologists. These incorporate neural implants, direct communication of raw emotion, artificial intelligence, rogue agents, and software to recognize and track people.

This book is a monumental achievement. The authors have provided a guidebook to a largely unexplored and immensely important territory. Reading it requires attention, effort, and exploration. Not reading it is likely to lead you out to pasture.

Technical Writing

2010-01-24T02:53:00.000-08:00

Before and during the dot-com boom, technical writing jobs in the US were plentiful and well paid. The ability to write coherent English sentences and use packaged software was sufficient qualification. Training in technical communication was not required, but certificate programs blossomed, and many new college graduates entered those programs. With the dot-com bust and the availability of high-speed communication between the US and India, many technical writing jobs became commodities and rapidly moved offshore. The number of people in the US identifying themselves as technical writers suddenly exceeded the available work. That number is now shrinking sharply to fit the demand. Many certificate programs have closed for lack of students.

Long before the dot-com boom and bust, however, a small cadre of academics and reflective practitioners established the underpinnings of a profession of technical communication. They showed how to determine the needs of their audiences and studied the most effective ways to satisy those needs. Some learned how to quantify the value that their work added to the products they documented. A few even learned the language of the business executives who determine the value that their organizations place on documentation. These academics and practitioners mostly survived, and they form the core of the technical communication workforce that exists today. Many, including me, are members of the Society for Technical Communication (STC), the leading professional organization for technical writers, as well as the IEEE Professional Communication Society and ACM's SIGDOC. A variety of online communities and mailing lists also support the field.

To be a successful technical writer today, you must understand the technical and business aspects of the work you do and how it affects the organizations who pay for that work. The book I look at this time covers all of the bases you need to touch.

Managing Writers: A Real World Guide to Managing Technical Documentation by Richard Hamilton (XML Press, Fort collins CO, 2009, 276pp, ISBN 978-0-9822191-0-2, xmlpress.net, 24.95)

Richard Hamilton began his career as a software developer in an organization that took software development seriously. His organization moved him directly from leading software teams to managing documentation, because they had begun to take documentation seriously as well. In the nearly 20 years since his first documentation management job, Hamilton has learned a lot about technical communication and how it fits into organizations like AT&T, Novell, and Hewlett-Packard. He has become an expert at applying XML technology to documentation projects and serves as a member of the OASIS DocBook Technical Committee. He is a member of STC.

Hamilton approaches the subject from the viewpoint of a manager, and he carefully covers everything that a technical writing manager should know. But writers who are not managers need this information as well. Technical writers in today's environment must understand the product, project, technology, and business issues. They must be comfortable communicating with the top leaders of their organizations, or those leaders are likely to regard them as commodities and their work as a cost that comes directly from the bottom line. On the first page of his book, describing the challenges facing technical writing managers, Hamilton says

Most important, technical documentation is viewed with disdain by many engineers and lives at the bottom of the power hierarchy in most companies. A significant amount of your time as a documentation manager will be spent working to gain respect, power, and leverage so you can do your job.

This sad fact applies to individual contributors as well. They must earn respect for themselves as members of the technical staff and of their project teams.

Hamilton gives an example of a situation in which he built power and influence. His firm issued annual updates of a complex product. The development groups were responsible for writing parts of a document describing their ongoing changes for the benefit of the support organization. When the writers needed clarification of the change document so that they could write clear release notes at the end of the year, the developers didn't want to provide information they thought they had already provided about features they had finished with months earlier. Hamilton's team took over preparing the ongoing change document, combined it with the release notes, and created an intranet site to simplify the developers' task of providing the new information and reviewing what the writers did with it. Hamilton's team thus gained control of the inputs they needed and won respect and gratitude for simplifying the developers' jobs and providing the support organization with clearer information.

Hiring and managing writers

Hamilton begins his book with a short summary of what technical writers do and the challenges they face. In a few pages he lays out his list of the key elements of technical writing: product, developers, audience, tasks, deliverables, environment, and schedules. Many writers focus on a few of these elements but ignore or skimp on others. Hamilton explains why each element is important and touches on the key issues associated with each of them.

Hamilton focuses on the three main aspects of managing: people, projects, and technology. These discussions become successively more abstract, though none of them strays far from concrete real-world situations. The discussion of managing people, however, seems close to Hamilton's heart. The examples are gripping; they deal with situations that should resonate at an emotional level with most readers.

Hamilton's longest chapter by far is on hiring, which shows the importance he attaches to that key activity. I have reviewed a number of books that talk about résumés. They present different, often contradictory, points of view. The message seems to be that there is more than one way to skin a cat. Hamilton details his process for evaluating résumés, and you won't go far wrong if you use it. He focuses on general themes rather than little details, and he shows a laudable level of flexibility. For example, he says he would hire a writer with only Windows experience to work on a Linux project, but he'd be reluctant to hire a writer who specializes in software to write an airplane hardware maintenance manual.

Hamilton makes a good point: the qualities that make a great technical writer boil down to the ability to understand and the ability to communicate. This seems obvious, but if you look at job ads, they often focus on tools, technology, and prior experience.

Hamilton is aware of the legal complications of hiring, managing, and occasionally firing employees. He contrasts the situation nostalgically with his father's situation as a personnel manager from the 1940s to the 1970s. He suggests making friends with people in the human relations department long before issues arise. This is the same advice Hamilton gives about building relationships with developers and with other managers. The pattern seems to be that good relationships lubricate formal processes. This is a tough lesson for introverts, a category that many technical writers inhabit. Many introverts would rather deal with processes than people.

Managing change

One of the most difficult problems of managing people concerns change. Most people adhere to the maxim, "If it ain't broke, don't fix it." It usually takes real pain to make people want to change. For example, if your company must translate your documentation into other languages, the potential costs are painful to the company's finances. Hamilton uses former General Electric chairman Jack Welch's metaphor of a burning deep sea platform. The managers standing on the burning translation costs platform feel the pain and are ready to act, but the writers may see it as someone else's problem as they watch from shore. The people who must make the change work must first understand and feel the need to do so.

Another common problem with managing change is to confuse the means with the ends. Hamilton tells us to define the desired future state in terms that impose minimal constraints on the means you use to get there. In particular, that means keeping solution vendors -- and consultants who are tied to specific vendors -- out of the process until you have a clear idea of where you are going.

Managing technology

New technologies present technical as well as personnel problems. Hamilton provides good advice about managing technology. For example, not every problem can be solved by technology. If you have badly structured content, don't count on a content management system to fix it. Figure out what you are trying to do and what obstacles are causing your pain. Articulate the desired final state. Then look for a solution, which may or may not involve new technology.

Once you have a solution, Hamilton suggests easing the personnel problems associated with the pain of adopting the change by phasing it in, providing good training to everybody, and keeping management in the loop -- especially when problems arise. It is better for them to hear about problems from you before they hear from your critics. One aspect of phasing in change is to start with people who have a positive attitude toward the change. Get the bugs out before bringing the troglodytes along.

Hamilton is a specialist in using XML technology, but he is also aware of the hype associated with it. He quotes Richard Feynman: "For a successful technology, reality must take precedence over public relations." The reality in this case is that it "will not organize your documentation, eliminate your production back-end, nor allow you to hire fewer, less skilled, or cheaper writers." XML is a system for producing markup languages (for example, DocBook or DITA). Such languages, when they integrate well with the structure of your documentation, help make your content easy to search, manipulate, reuse, and repurpose. Hamilton provides useful guidance in addressing these issues. There is no magic. You may have to make substantial investments before you begin to realize any of the benefits.

Many technical writing managers must deal with complex problems like single sourcing and localization. For such problems, the solution often includes some sort of content management system. Hamilton explores the issues involved in setting up processes to support single sourcing and localization. He also talks about how to decide what sort of technological help you need in managing content.

While many vendors cite reuse as one of the main purposes of a content management system, Hamilton advises you to start by organizing your content in such a way as to minimize reuse. He considers it better to have just one logical place to look for a piece of content than it is to have it in different places, even if you have a system for synchronizing the content at those different places.

Resisting the dark side

One reason I am so enthusiastic about this book is that Hamilton is not in awe of sacred cows. Two of them are performance evaluation and performance metrics.

Business success depends on clear expectations between managers and their employees. They need a framework for ongoing discussion of goals, objectives, and other workplace issues. Weekly one-on-one meetings often provide this framework. On top of that, however, most companies use an annual performance evaluation process. This could be a beneficial way to focus on long term issues, but most companies use it for a different purpose: sorting employees into winners and losers. This robs the process of many good effects it might theoretically have had. Neither managers nor employees can engage openly and honestly in the process, because they are aware of its negative consequences.

Nonetheless, Hamilton recognizes that almost all companies have a performance evaluation process. Eisenhower said something to the effect that plans are useless but planning is indispensable. Hamilton applies that model to performance evaluation. He does what he can to make the process of performance evaluation helpful. He suggests ways to do as little harm as possible with the resulting documents and the ensuing discussions with employees.

Hamilton devotes approximately a quarter of his book to managing documentation projects. He makes points I haven't seen in substantially longer works on the subject, but I especially like his discussion of metrics. There is a cliché to the effect that if you don't measure something you can't manage it. Furthermore, keeping good records of predicted and actual values of some metrics helps to improve planning and estimating. Despite their benefits, however, metrics have downsides. Writers are aware that management may use these metrics to evaluate performance, so the measured aspects improve to the detriment of the unmeasured aspects. Unfortunately, the easiest aspects to measure are not likely to be the most important. For example, it is easy to count pages and hard to measure quality.

As with performance evaluations, Hamilton shows how to make the best of a bad tool. He delegates measurement to individual writers to use as they see fit, and he solemnly promises not to use those measurements to reward or punish writers -- or report the measurements to anyone likely to use them in that way.

Hamilton has much more to say about managing people, projects and technology. This short book is full of useful information and hard-earned opinions. Whether you manage writers or would rather just sit in your cubicle and write, you need to read this book. It is the most practical and realistic book I have seen on the subject, and I recommend it highly.

Life and Work

2009-10-07T19:59:00.000-07:00

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

The Declaration of Independence of the United States of America declares that every person has the right to life, liberty, and the pursuit of happiness. These are precious rights, but exercising them takes work. Pursuing happiness entails overcoming many obstacles. The easiest and hardest of these are often in our own heads.

Recently I attended a workshop called Strategic Planning for Your Life, led by Judy Glick-Smith, a former president and Fellow of the Society for Technical Communication (STC). That workshop is not the subject of this review. You can find information about it at www.mentorfactorinc.com. Glick-Smith's method asks you to begin by discovering what makes you happy and casting aside the internal obstacles to pursuing that happiness. She then lays out steps whereby you can arrive at a set of life goals and an ongoing process for pursuing and updating them.

By whatever path you arrive at your life goals, they are likely to include some sort of productive work. If that work is a high-tech job, I can recommend a book to help you.

Land the Tech Job You Love by Andy Lester (Pragmatic Bookshelf, Raleigh NC, 2009, 272pp, ISBN 978-1-93435-626-5, www.pragprog.com, $23.95)

Andy Lester has been writing software since the mid-1980s. He is active in the Perl community, where he maintains more than 20 modules on the Comprehensive Perl Archive Network (CPAN). In the course of his professional life he has seen countless résumés, interviewed many candidates, and done his share of job hunting as well. His frustration at what he has seen led him to write this book.

Many people give job-hunting advice. Most are dogmatic about their recommendations, even though one effective job hunter may give you rules that contradict those of another equally effective job hunter. Lester is no exception. He is sure of his rules, though he recognizes that they may not apply to your situation. Hardly anybody, however, is likely to disagree with the basic principles he starts with:

Be honest with yourself.

Be honest with others.

Think like the boss.

Be a problem solver.

Sell yourself.

Tell stories.

Be positive.

Lester begins from the premise that life is too short for a job you don't love. Being honest with yourself is a key to ensuring that you don't wind up in a job that you don't love. Lester urges you to think about what you want in a job before you start looking at job ads or writing a résumé. Following one of his own principles, he tells a story of how he had taken a seemingly perfect job and found it to be unbearable. He hadn't aksed himself what he really wanted in the job. Had he done so and given himself honest answers, he would not have taken the job.

Once you decide what you want in a job, it's time to think about a résumé. Lester identifies what he considers to be the basic sections of a résumé and tells you how to gather and organize the contents of each. There are no surprises here, but his systematic coverage can help you ensure that you haven't overlooked anything.

Lester also identifies material that you should not include. Some of this is uncontroversial -- for example, don't include a photo or any information that you can't legally be asked about in an interview. Cautious hiring managers will discard such résumés without looking further. Some of his other rules, however, may cause raised eyebrows. Some experts suggest beginning a résumé with an objective, but Lester considers objectives to be useless fluff, often filled with meaningless phrases like "challenging position" and "contribute my skills." And if you ever apply for a job for which Andy Lester is the hiring manager, don't waste space on your résumé with the phrase "references available on request."

Once you have the basic building blocks, Lester wants you to put them together in a variety of ways. Of course you need a generic résumé on paper and in electronic form, but that's just the beginning. Ideally, for example, you should create a separate résumé for each position, tailoring and arranging the parts to highlight the ways in which you meet that job's requirements. Furthermore, you need versions in various formats. Some hiring managers ask for résumés in Word format, while others want text, and you should also have a generic HTML version on a publicly accessible website. If someone asks for Word format and you send them PDF, they already know that you can't or won't follow directions. Lester has much more to say about résumés, and it's worth reading, even if you don't agree with all of it.

After all of this groundwork, you have to find a job to apply for. Lester wisely steers you away from "job boards," websites that treat candidates and jobs as fungible commodities to be matched with one another. He also distrusts recruiters, because their clients are the hiring firms. You might think that recruiters find positions for candidates, but their actual job is to find candidates for positions. Instead of using job boards and recruiters, ask the people you know -- including your Aunt Edna, but excluding your current co-workers -- to help. Help can take many forms, but Lester advises keeping it lightweight. Ask for pointers and leads that you can follow up on. Don't ask anyone to do your job hunting for you.

Another piece of good advice that Lester offers is to use traditional sources like newspapers or the local Chamber of Commerce. Newspapers can give you a high level view of what's available in the area they serve. The staff of the Chamber of commerce can probably give you pointers to valuable contacts inside firms that need your services.

Once you find some interesting job possibilities, there is more to do before you send anybody your résumé. Lester tells you how to use publicly available sources like a company's website or its Securities and Exchange Commission (SEC) filings to answer the key questions: how does this company make money, how could I help it make money, and would I enjoy doing so? Remember, life is too short for a job you don't love.

Lester suggests using online resources to help you find information about a company. You might discreetly approach a current or former employee who posts to a technical mailing list that you belong to. Or you might look on the Facebook or LinkedIn social networking sites for people whose profiles mention the company.

Once you've found out everything you can about the company, it's time to apply for the job. Many people will tell you to send your résumé with a cover letter, but Lester points out an aspect of cover letters that you may not have thought of. If you can't come up with two paragraphs that explain why you are a good match for the specific job and company, you probably shouldn't apply.

Jack Molisani, a recruiter who often makes presentations about job hunting, tells the story of a résumé he sent to a client who wanted someone with patent experience. The client called him back and asked why Molisani was wasting his time with a candidate who didn't have patent experience. The résumé mentioned the candidate's patent experience, but not near the top, and the client hadn't read far enough to find it. This illustrates several of Lester's points. One point is that if interviewers ask you questions that your résumé clearly answers, don't say "read the bleeping résumé." Molisani knew better than to call his client's attention to the material the client had overlooked.

A second point that Molisani's story illustrates is that you should look at your résumé through the eyes of the hiring manager. Think about what is important to the hiring manager and make that part of your experience prominent on the résumé. I agree with that point, but I disagree with the method Lester suggests for making parts of your résumé prominent. Lester suggests highlighting words of the résumé that are important to the specific job by making them bold. This is a dangerous technique. A skillful communicator might get away with it, but most job candidates are likely to wind up with résumés that look like a ransom notes. Other techniques that Lester also advocates are more effective. Rearrange the sections of the résumé to highlight the most important information, and mention key points in the cover letter. By all means, tailor the résumé and cover letter to the job, but go easy on the bold.

While Lester rightly encourages you to follow directions and give hiring managers what they ask for, he makes an exception for salary history. Never provide this information. It's nobody's business, and there is no benefit to providing it. Lester suggests finessing this request by politely but firmly noting that the information is confidential and that it's not a subject that you discuss with anyone.

When the company invites you to a job interview, you're almost there. Unfortunately, many candidates perform badly in interviews. The hiring manager is likely to prepare carefully for the interview, and you should do the same. This includes preparing logistically. Arrive on time with whatever materials you need to bring with you. Clear your schedule, so you can stay as long as necessary.

There are many ways to look at interviews. They are conversations in which you can lead as well as follow. They are sales pitches by which you show that you are the right person for the job and make the hiring manager eager for your services. They are a first day on the job in which you seek out the areas where the company needs you most. Unfortunately, they can also be an obstacle course in which the hiring manager seeks to trip you up with questions designed to eliminate candidates and simplify the hiring choice. Lester prepares you for all of these aspects of interviews.

One piece of advice that Lester provides applies to many of life's situations -- not just to interview questions. Listen, and seek to understand not just the question, but the reason for the question. Remember that an interview is a chance for each party to decide whether they would like to work with the other. Sometimes understanding the reasons for questions can help you with your half of that decision. And being sure you understand a question before you answer it can keep you from saying something that makes you look uninformed or ill-prepared.

Lester also provides a lot of advice that you've probably heard before, but it can't hurt to keep it in mind. Arrive a little early. Treat everbody like the CEO -- especially the receptionist. Stand to shake hands. Make eye contact (but don't stare). Be positive. Ask for the job.

I do not completely agree with Lester about how to handle a portfolio. I learned about how to use portfolios from Lance Gelein, another former president of STC. To Gelein a portfolio is a set of impressive props to use while telling stories. If the conversation comes around to a specific kind of job, you open your portfolio to a sample of that sort of work and tell the story of how you approached it, what obstacles you faced, and how you overcame them. The portfolio piece is not the entire job, but a snippet that you can point at while telling the story. Your portfolio does not stand alone without you. You never leave it with the hiring manager or let anyone look at it without your accompanying narration.

To Lester, a portfolio is a collection of representative pieces of work that you are proud of. Each stands alone, and you happily leave a copy behind for the hiring manager to peruse after you've left. There is, of course, a place for this sort of work sample, but it doesn't fully exploit the story-telling potential of a portfolio.

Lester devotes an entire chapter to tough interview questions. Again, the key is to understand the reason behind the question, so you can directly, without equivocation, satisfy the interviewer's concern. Lester identifies a number of red flags that interviewers want to uncover. Some of these are two-edged swords. For example, do you refuse to ask for help? Are you unable to work without constant hand holding? Interviewers ask questions designed to detect where you stand with respect to these extremes. If you recognize what they are getting at, you can give a useful answer. Don't try to duck questions like "What is your greatest weakness?" or "Tell me about a project that didn't go well." Lester shows you how to approach such questions.

Lester's advice doesn't stop with the interview. He covers follow-up, dealing with an offer or with rejection, and even how to stay hirable after you start the new job. He has written a short but comprehensive book -- easy to read and full of good advice. Like every other book about job hunting, this one is not perfect, but if you absorb its advice and adapt it to your situation, it should pay for itself long before your first hour on your new tech job is complete.

Twitter

2009-08-11T02:41:00.000-07:00

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

The Twitter social messaging service is simple, but hard to understand, at least at first. I poked around its edges for a while, until I found the Twitter Book.

The Twitter Book

The Twitter Book by Tim O'Reilly & Sarah Milstein (O'Reilly, Sebastopol CA, 2009, 240pp, ISBN 978-0-596-80281-3, www.oreily.com, $19.99)

Tim O'Reilly is the founder and CEO of O'Reilly Media. I have never before reviewed a book that he wrote, but I have been reviewing books that he published for about 20 years. Starting with a few how-to books for Unix users in the 1980s, O'Reilly Media has become the leading publisher of books about hot software topics. In recent years, Tim O'Reilly has become a leader in the open source and web 2.0 communities.

Sarah Milstein started out as a freelance writer and editor. She was a regular contributor to The New York Times. Later she joined O'Reilly media, where she led the development of the Missing Manual series. She now travels around the country, lecturing and teaching about Twitter. With fellow Times contributor Marci Alboher, Sarah is cofounder of 20slides.com, which will soon launch a series of career-related online workshops.

The Twitter Book has been my gateway to Twitter. It contains solid basic information about all aspects of Twitter and provides context for a large number of pointers. By following those pointers, I learned everything I know about Twitter. If you invest a few hours reading this clear and comprehensive book, you will be well on your way to understanding how Twitter fits into your life.

Basics of Twitter

To begin using Twitter, go to twitter.com and sign up. Supply your full name, and pick a username that is short and to the point. My username is xrmxrm, which includes my initials and echoes my email addresses and Facebook ID. No username that includes a significant indication of my full name would be short enough to be an effective Twitter username.

Next, set up your profile. Twitter allows you a picture, a 160-character biography and a location. My biography is:

Technical communicator specializing in documentation for programmers -- APIs, web services, programmer guides. Columnist for IEEE Micro.

My location is Berkeley, CA.

Your name, your location, your biography, and your contributions are all that a person considering following your contributions has to go on.

Before using Twitter, you should understand updates, following, @references, retweeting, hashcodes, and searching.

Updates, also called tweets, are your contributions. You can enter a message of up to 140 characters, and everyone who has signed up to follow you will see that message, with your picture, among the tweets that come to them. Anyone can follow your updates, unless you protect updates, which few people do, because there is little point to doing so. You can send updates from a browser or a third party Twitter client, on your computer or your cell phone.

Following is an easily established asymmetric relationship between you and another twitter user. You simply go to that user's page (twitter.com/their_username) and click the Follow button. You can follow other users without their permission and without their following you. Twitter will, if you choose, notify you by email when other users choose to follow you. If you like, you can view their pages and decide whether to follow them. Many people automatically follow people who are following them, but there is no need to do so. Some people follow you as a form of spam. Obviously, you should not follow them. Twitter provides an easy way for users to report spam.

The most interesting uses of Twitter are conversational, so you need a way to refer to other people's tweets. Twitter interprets content of the form @username as a link, called an @reference, to that user's page. By a quirk of Twitter, if you begin a tweet with an @reference, most Twitter users who follow you but do not follow the user referred to in the @reference will not see the tweet. As a result, if you want to pass a tweet to your followers, a process called retweeting, you should place the @reference in the body of the tweet. The standard formats for retweets are to begin with RT @username or to end with via @username.

Twitter has a powerful search mechanism. In addition, it automatically brings to your attention the topics that are most popular at the moment. Search results can contain the tweets of users you are not following, so searching enables you to follow interesting trends and find interesting users to follow.

Often, a group of users interested in a topic choose a search term to include in tweets about that topic. Such search terms usually begin with hash mark (#). These are called hashcodes. As I write this, #iranelection and #michaeljackson are widely used hashcodes. Nobody assigns hashcodes. Users simply start using them. Different versions soon converge, and conflicts work themselves out.

Twitter Helpers

Twitter provides a certain amount of pushed summary information. In addition, a number of third parties follow Twitter, massage the flow of tweets, and make the information easily available. They can notify you about matters of interest to you, so you don't need to read millions of tweets each day. For example, TwitScoop shows hot topics as a tag cloud, in which terms appear in larger or smaller font sizes, depending on their recent frequency.

Another difficult problem for most new Twitter users is deciding which users to follow. Sites like MrTweet provide personalized lists of Twitter users for you to consider following.

If you want others to find your tweets worth reading and retweeting, you should link to interesting material. URLs can be long, and Twitter's limit is 140 characters for your entire tweet, so you need to find a good URL shortener. Such services (for example, TinyURL, Bit.ly, is.gd, and Twi.bz) replace a long URL with a unique, permanent short one that points to the same place. Different shorteners provide different advantages. For example, some give you some control over the resulting URL, while others make it easy for you to track clicks.

Pictures are a compelling component of many tweets. You can post a picture to a site like flickr.com and use a shortened URL to point to it. Others can leave comments at the site or retweet the link with their comments. The twitpic.com site integrates especially well with Twitter.

If you interact with Twitter solely through twitter.com, the primitive user interface soon becomes limiting. You must refresh the page to see new tweets. Simple tasks like replying and retweeting entail tedious manual steps that cry out for automation. Because Twitter provides an application programming interface (API), many third parties have created programs to put a different front end on Twitter. Most such programs run on computers, but others work on smart phones. I have tried Twhirl, SeesmicDesktop, TweetDeck, and DestroyTwitter on my laptop. Each provides improvements over the twitter.com interface, but I keep coming back to twitter.com because I feel more comfortable and less restricted there.

One drawback of the clients I've tried is that they provide little in the way of accessibility. I like to change window sizes and enlarge the text and graphics on my screen. This is easy to do in most browsers. The clients I tried, however, all use Adobe Air. If Air provides that sort of control, these clients haven't figured out how to make use of it. Or if they have, they haven't made it clear to me how I can use it. For that matter, the same criticism pertains to Adobe FrameMaker, which uses Air as the delivery environment for its online help.

What Twitter Is and Isn't

Twitter enables people to share facts, opinions, news, and commentary about everyday life or extraordinary events.

Recently Scott Williams posted an article at http://bigisthenewsmall.com/?p=2170 called Seven Things Twitter Is Not. He makes the point that Twitter is like a river. You can stand on the bank and watch the tweets go by. They are not piling up in your mailbox. Nobody expects you to answer them. If you do toss a tweet into the river, it flows away quickly. Someone may retweet it or reply to it, but the reply floats away too. It may include some context, but 140 characters soon become inadequate to contain an ongoing chat.

Another interesting metaphor is that of a great collective consciousness. As you watch the river, a subject may suddenly attract your attention. For example, on November 26, 2008, reports about the terrorist attacks in Mumbai spiked suddenly on Twitter, drawing worldwide attention before the news media could react.

One frequently asked question about Twitter is, "How can I use it to make money?" Twitter does not seem to have answered that question for itself, but many businesses have found ways to integrate Twitter into their ongoing relationships with actual and prospective customers. The Twitter Book devotes a substantial section to the do's and don'ts of using Twitter for business. No business should jump into Twitter until its management understands the principles that O'Reilly and Milstein lay out there.

You may not understand Twitter at first, but if you try it patiently for a while and get a sense of how others are using it, it will grow on you. Go to twitter.com and give it a try.

Software Architects

2009-06-01T22:31:00.000-07:00

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

This time I look at a collection that, according to its editor, is completely different from any other book you've read. That statement is true of any book, I suppose, but this book is unusual.

97 Things Every Software Architect Should Know: Collective Wisdom from the Experts edited by Richard Monson-Haefel (O'Reilly, Sebastopol CA, 2009, 218pp, www.oreilly.com, ISBN 978-0-596-52269-8, $34.99)

Richard Monson-Haefel is a co-author of the O'Reilly books Enterprise Javabeans and Java Message Service. The project grew out of a presentation called 10 Things Every Software Architect Should Know, which he was planning for a No Fluff, Just Stuff symposium. He solicited inputs on a mailing list, and nearly 50 people contributed the "things" that became this book. Each fills a pair of facing pages and includes a contributor photo and brief biography. The regularity of the structure ends there.

The free format allows contributors to formulate their wisdom in whatever ways work best for them. They address a variety of subjects in a variety of ways, but looking at the book as a whole, I see themes emerge. They have very little to say about project retrospectives or managing risk, so I hope they will all read two excellent books from Dorset House. Norman Kerth's Project Retrospectives (Micro Review, May/June 2001) and DeMarco & Lister's Waltzing With Bears (Micro Review Jul/Aug 2003) are essential reading for any software architect.

Communication

Communication receives a lot of attention in this book. Udi Dahan of Microsoft, for example, advises you to stand when you speak to a group. It makes people take you more seriously.

Other contributors stress the importance of knowing both the language of the business decision makers and the language of the software developers. Communication failures between the two groups cause many project problems, and these contributors assign to architects the responsibility for making that conversation work.

Norman Carnovale of Lockheed Martin Professional Services emphasizes the importance negotiating with the business decision makers to ensure that mid-project changes don't lead to unrealistic schedules and ultimately to failure. David Muirhead of the Blue River Systems Group recognizes that the business must drive a project, so he advocates developing the kinds of information that business leaders can use to make good decisions. Yi Zhou lays out the elements that make up a strong business case for a proposed expenditure.

Michael Nygard reminds us that we should remember the difference between a negotiation and an engineering discussion. When business decision makers ask "do you really need x," the answer should be "yes" if that's what the analysis led to. In an engineering discussion of the point, you might say "you could do without it if . . ." but business decision makers won't hear the "if" or anything that follows it.

Another communication theme is that architects must manage their own attitudes so that they can engage in open conversations with developers and customers. They must not let overconfidence or arrogance prevent them from hearing the good ideas of others or listening to the specific needs of customers.

Timothy High of Sakonnet Technologies gives advice that is easy to follow but often ignored. He advocates recording the rationale for decisions. He questions the value of most design documentation because it is hard to keep up to date. The rationale for decisions, on the other hand, doesn't require changes and is a valuable resource for the life of the project.

Requirements

Another theme of the book is requirements. Understanding, examining, and negotiating requirements and turning them into specifications is one of an architect's key jobs. Everyone understands that this process is a negotiation that must balance the needs of customers, funders, and developers. Eben Hewitt puts forth the beautiful metaphor of a consommé -- an extremely clarified broth achieved by repeatedly straining out the solids that cloud it. You must test the language of the requirements again and again until it is clear. This reminds me of the Mary Had a Little Lamb heuristic in Gause & Weinberg's Exploring Requirements (Micro Review, Sept/Oct 2001), another book that all software architects should read.

Many of the contributions boil down to pushing back against stated requirements in various ways. Einar Landre of StatoilHydro advises seeking the value in the requirement. He tells the story of the F-16 Falcon aircraft for which an initial requirement was speeds of Mach 2 to 2.5. By asking why, the contractor was able to change the requirement to an agile aircraft that can accelerate quickly to escape from combat. Similarly, Eben Hewitt tells you not to rush to solve the problem. First interrogate it to see if you can change it into a more tractable one.

Keith Braithwaite of Zuhlke exhorts us to quantify requirements. Fast, responsive, and extensible, for example, are terms that mean different things to different people. Developments based on such terms can lead to serious disputes at acceptance time.

Assumptions, as we all know, can be dangerous. Timothy High advises us to challenge assumptions, especially our own. Urban myths -- or even facts that used to be true -- can lead us away from excellent solutions to design problems.

Not all requirements can or should be satisfied. Good design involves tradeoffs. Mark Richards of Collaborative Consulting recounts the story of the Vasa, an early 17th century Swedish ship that satisfied all of its requirements and sank the first time it fired its guns. Bill de hÓra of NewBay Software says that requirements often come in threes (like fast, cheap, and accurate) and that you should be prepared to pick two and jettison the third. When a requirement seems absolute, be skeptical and ask why. Dave Quick of Thoughtful Arts puts it another way: Scope is the enemy of success. The greater the scope, the worse the chances of success.

Another way to test requirements, according to Stephen Jones, is to stretch key dimensions to see what breaks. This kind of stress testing can identify future problems long before they occur. It enables the necessary changes before the design becomes set in stone.

A number of contributors show concern for end users. Your customer may not be the end user, as Eben Hewitt points out, but your customer won't succeed if the system serves end users poorly. Keith Braithwaite, following Heidegger, uses the german term zuhanden to suggest that systems should be invisible to users. However, Steve Talbott in Devices of the Soul (Micro Review, July/Aug 2007) takes the opposite point of view: 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.

Pitfalls

Many contributors offer advice about pitfalls and how to avoid them. Avoiding unnecessary complexity or generalization is a common theme. Neal Ford of ThoughtWorks defines accidental complexity as the complications that arise as byproducts of addressing the essential complexity of the problem. Often accidental complexity comes from adopting frameworks that are too general or fail to match the problem.

Kevlin Henney puts it another way: simplicity before generality, use before reuse. Eric Hawthorne says to choose frameworks that stick to their own domain and don't impose unnecessary requirements. Keith Braithwaite points out that the real world has multiple, inconsistent, overlapping frameworks. Sometimes it works to use each in its own domain. Or as Randy Stafford of Oracle puts it, there is no one-size-fits-all solution. Exercise contextual sense to understand what works in a given domain.

The editor of the book, Richard Monson-Haefel, contributes his own pitfall. Avoid trying to future-proof the system, because you can't predict the future. Trying to guess the technologies of the future can lead to analysis paralysis.

Design and Development Approaches

As you would expect in a book about architecture, design and development approaches receive a lot of attention. Most contributors implicitly or explicitly advocate iterative and incremental processes. Bill de hÓra summarizes this view by saying that great software is grown, not built. Similarly, David Bartlett advocates Martin Fowler's continuous integration (CI) approach, which includes automated builds and testing at frequent intervals.

Dan Chak of CourseAdvisor, however, focuses on designing the underlying database. He feels that the data structures and relationships that underlie applications do not evolve rapidly and require a complex, comprehensive technical design up front. The resulting solid and self-protective data fortress will save application data from the inevitable bugs in the application level.

George Malamidis of TrafficBroker adopts the language of business. He says that every architectural decision is an investment. You should consider the return on investment (ROI). This is true whether you use an agile process or the waterfall model.

George Holpe of Google says welcome to the real world. He implies that most software engineers are clinging to a bygone world of predictably ordered processes controlled by the program rather than by external events. In that world, systems are tightly, rather than loosely, coupled. He quickly tears down that straw man, using the word "scary" a couple of times to characterize the new environment. I get his point, and he's certainly right about the need for distributed, loosely coupled, event-driven systems, but I'd like to point out that we were building event-driven systems in the 1960s, so the idea isn't all that new.

Several other contributors also use uncertainty to their advantage. Kelvin Hanley suggests than when you come to a fork in the road, design so that choosing between the two branches has fewer consequences. Erik Doernenberg of ThoughtWorks suggests trying both branches and deferring the choice until it's obvious which is better.

Performance and Maintenance

Most of the life of a successful software project happens after its initial installation. Many of the contributors address issues about performance and maintenance.

Randy Stafford points out that application architecture determines performance. Rebecca Parsons of ThoughtWorks advocates beginning performance testing early in the development process. This can help you identify problems early. It also gives you an ongoing record that shows which changes helped or hurt performance. Craig Russell of Sun Microsystems takes a broader view and advocates looking at the performance of the developers implementing the design.

Tools and Techniques

I don't have room to go into all of the suggestions about tools and techniques. One that tickled me is Paul Homer's suggestion that you can get a good idea of how a system works by looking at its underlying data structures. In 1967 I attended Butler Lampson's course on operating systems at UC Berkeley. Lampson made exactly that point.

Architects

Many contributions address the necessary qualities or skills of software architects. Many see themselves as leaders of the development project and focus their comments on how to interact with developers. Many say to lead by example or to keep a hand in the development work. The objectives are to maintain the respect of the developers and to experience the design from the point of view of a developer. It's easier to recognize design mistakes if you're the one who has to implement them.

Many stress the importance of maintaining respectful and open relationships with developers. Evan Cofsky of Virgin Charter invokes a taxonomy in Neal Stephenson's Cryptonomicon. Architects are kings and must provide opportunities for elves, dwarves, and wizards.

Many also look at the social or ethical aspects of an architect's work. Barry Hawkins advises valuing stewardship over showmanship. As he points out, you are playing with other people's money. Michael Nygard points out that many decisions restrict or enable end user behavior. A few days of programming time may save end users a few seconds each time they use a feature. With many users and many repetitions, that could be a huge savings for them, but at a cost that you won't recoup. It certainly raises an ethical question.

Yi Zhou tells architects to take responsibility for their decisions. That means putting it in writing and communicating it to everybody it affects. You must also follow through to ensure that developers implement your decision, and you must review the decision periodically to see how it's working out. Taking responsibility also means not making decisions that you're not qualified to make. Delegate those decisions to experts.

I hope this review gives you an idea of the flavor of the book. If you design software, you're sure to find enough nuggets of information in it to justify its price many times over.

Software Testing, Freelancing

2009-04-01T21:10:00.000-07:00

This time I look at two subjects that confuse a lot of people and give rise to a great deal of wishful thinking. Misconceptions about software testing can cause great damage to large and small enterprises. Misconceptions about freelancing can be catastrophic for individual entrepreneurs.

Software testing

Perfect Software and Other Illusions About Testing by Gerald Weinberg (Dorset House, New York NY, 2008, 198pp, www.dorsethouse.com, ISBN 978-0-932633-69-9, $29.95)

Testing is a sampling process designed to obtain information to use in decision making. Some testing activities entail banging on a keyboard, but many others do not. Suggesting a design review, for example, is a form of testing and a developer's reason for not wishing to submit to a review can be a useful test result. Many people see testing purely from the banging on keys point of view. That and other misconceptions lead to painful consequences for them. Gerald Weinberg, a self-described empathic person, has written this book to ease their pain.

Weinberg has been in this business a long time. He was an old timer in 1973, when I first read his enormously influential Psychology of Computer Programming, and he has been an effective and productive writer and consultant in the field of developing and testing software ever since. I have reviewed several of his books in my columns over the years. In addition, many books by other authors, especially those published by Dorset House, show the profound influence of Weinberg's style and approach.

The insights of the late Virginia Satir, a family therapist, inform this book, as they inform much of Weinberg's work about the social aspects of managing software development. Weinberg applies Satir's decomposition of communication into intake, meaning, significance, and response to structure his lessons about how to use testing. He also uses her insights about defensiveness and survival rules to understand the natural immunity to information that people often experience in threatening situations. Nonetheless, there is no new-age mumbo jumbo in this book. Weinberg translates all of his psychological insights into practical terms.

The book's title fallacy concerns the widely held belief among the general public that companies could produce bug-free software if only they tested everything before selling it. This belief falls apart upon cursory examination. Testing "everything" is not possible in a finite amount of time. Furthermore, while testing can identify problems, it cannot correct them. Testing can only provide information. Those in charge of a project can use that information to help them assess the risks associated with various options -- such as shipping the product or sending it back to the developers for more work. This decision is not always easy, because fixing one problem often leads to introducing or uncovering another, sometimes more serious problem.

Because testing can only provide information, you should test only if you need information to help you make a decision. Furthermore, written test reports rarely tell everything that the testers know, so if you want your money's worth from testing, you need to question and interpret the results. It also follows that testers do not produce decisions. Bad managers ask testers if the product is ready to ship. Good managers ask testers what they found, then use that and other information to help them make their own decisions.

Weinberg has seen the insides of far more projects than most of us have and has worked with some relatively dysfunctional organizations. His stories of scapegoating, intimidation, and other misuse of testers are hair raising. If you work under such conditions, you need to read this book right away.

Weinberg seems to have developed a special style just for this book. His chapters average about nine pages. Each ends with a short summary and a long list of common mistakes. The mistakes section reiterates the earlier chapter material in negative form. For example, his chapter on information intake explains why you should choose which information to look for among the large amount of raw data available to you. The first common mistake at the end of the chapter is "Not thinking about what information you're after. Don't just take what comes. You have choices."

As in many of his other books, Weinberg presents some lessons in the form of vignettes. For example, he builds his chapter about major testing fallacies around a few hours in the life of Rose, the new testing manager. The dialog is contrived, and the realistic touches (Rose spears a pickle with her fork and waits for Barry to finish his chili) are lame. Nonetheless, Weinberg uses this form effectively. He shows how the pressures on the different players combine with their partial understanding (or misunderstanding) of the situation to lead to scapegoating, turf battles, and finger pointing.

Weinberg presents a breakdown of bug fixing that accounts for a lot of inefficiency and delay in software development projects. Testing can uncover an anomaly, after which further testing merges into another phase called pinpointing, or isolating the conditions under which the anomaly occurs. Failure to agree on who is responsible for pinpointing leads to many conflicts between testers and developers.

Pinpointing leads to locating, which means determining the section of code in which the problem resides. Few organizations regard locating as part of testing, but a desperate developer might be tempted to return the bug to the tester for "more information."

Between locating and fixing comes another important step: determining significance. This is a management function belonging to neither testers nor developers. Many stakeholders can contribute to this process. Ultimately, someone must weigh the costs of both alternatives. Fixing the bug takes time and effort and might break something else. Leaving it as is can result in other costs, such as service calls or lost sales.

One of the biggest problems associated with testing is how it interacts with the schedule. In an ideal development process, testing begins before the project, because deciding whether on not to do a project depends upon information gleaned from some form of testing. Then testing continues through all phases of the project. Unfortunately, most project managers follow a different model.

Typical projects have schedules that include a block of time labeled testing at the end. This block does double duty as a buffer to accommodate slips in the development schedule. In a good project, testers participate in reviewing the usual project artifacts -- market requirement documents, functional specs, user interface specs, detailed design specs, and documentation plans. In a bad project they may be handed a functional spec and told to develop a test plan that tests everything. In either case, unless they work alongside the developers throughout the project, they do not usually find problems until long after those problems enter the product. What could have been fixed easily months earlier now becomes an obstacle to delivery. A project that was "on schedule" until the testers got hold of it is now in danger of slipping. At that point, it's easy to blame the problems on testing.

Another distinction that Weinberg makes is between testing and demonstrating. If you know the "test" result in advance and are only running it to give potential customers a good feeling, you are not testing. Testing always seeks to find new information. Somewhere near the level of Gianni Schicchi in Weinberg's Inferno are the sellers of expensive testing systems who use such fake tests to support unsupportable claims about their products. Vendors who claim that their products will do all the work without receiving extensive explanations about what the programs they are testing are supposed to achieve are simply charlatans in Weinberg's view. Weinberg is firm in his belief that machines will never replace brains when it comes to software testing. Testing is an interactive process of investigation in which each finding leads to new questions.

Like all of Weinberg's books, every page of this one has wonderful insights and advice. If you have anything to do with software development, you should get a copy and read it at least twice.

Freelancing

The Principles of Successful Freelancing by Miles Burke (Sitepoint, Collingwood Australia, 2008, 206pp, www.sitepoint.com, ISBN 978-0-9804552-4-3, $39.95)

SitePoint is a small publisher targeting web professionals. Its books deal with SQL, CSS, HTML, ASP.NET, and similar staples of the browser-based world. Miles Burke is a freelance web developer, and he has written a book for others who wish to enter that arena.

I confess that I was put off by the lax editing and the Australian jargon of this book, but if you can get past that, it has a lot of useful content for people who want to set out on their own. Other books for freelancers (for example, Secrets of Consulting by Gerald Weinberg) focus on advanced topics. This book lays out the basics. If you read this book carefully, you won't make any major omissions as you prepare for your freelance career. In fact, at every stage, Burke puts on the brakes and urges you to move slowly.

Many people jump into freelancing because they have just lost their jobs. Such an approach has little chance of success in most cases, because starting a business requires a financial cushion that few recently fired workers have. Also, those who have never worked for themselves may overlook expenses like self-employment taxes, insurance, sick days, vacations, and the like. Burke shows you how to make the necessary computations and set your rates accordingly. You may have to adjust a little if you don't live in Australia, but many of the points he makes apply in the USA as well.

Burke covers all the bases -- from not using stolen software to negotiating with your family for an efficient work area in your home. He also gives good advice about how to find work, how to relate to clients, and how to balance life and work when they all happen in the same place.

If you are considering a career as a freelancer, especially in the web design area, you should find this book well worth its price.

Hot, Flat, Crowded

2009-02-02T01:44:00.000-08:00

The Italian political philosopher and pragmatist Niccolo Michiavelli once wrote about the difficulties of change. An English version of his much quoted aphorism is as follows:

There is nothing more difficult to plan, more doubtful of success, more dangerous to manage than the creation of a new system. The innovator has the enmity of all who profit by the preservation of the old system and only the lukewarm defense of those who would gain by the new system.

This time I look at a prescription for a new system for dealing with the world's energy needs.

Hot, Flat, and Crowded: Why We Need a Green Revolution and How It Can Renew America by Thomas L Friedman (Farrar, Straus and Giroux, New York NY, 2008, 448pp, ISBN 978-0-374-16685-4, $27.95)

Tom Friedman has been with the New York Times since 1981, when he signed on as an energy reporter. He is now a foreign affairs columnist. His first two books deal with the Middle East. His third, The World Is Flat (see Micro Review, May/June 2005), deals with globalization. In this, his fourth book, he returns to energy, bringing to bear his broad understanding and experience of global issues and the Middle East. Though the book is about global systems, he has written it as an American and addressed it to Americans.

Friedman uses the phrase "hot, flat, and crowded" to refer to the three themes that are pushing the world into what he calls the Energy-Climate Era:

Global climate change.

The emergence of new, globally connected middle classes in China, India, Russia, and elsewhere.

Worldwide population growth.

He calls it the Energy-Climate Era, because energy and climate are the principal issues that the world will face for many years to come. These issues underlie and manifest themselves in the following big problems:

Increasing population and the rise of middle classes have led to a sharp increase in demand for natural resources and energy.

The huge amounts we spend on crude oil and natural gas have strengthened dictatorships in Russia, Venezuela, and the Middle East and funded some of our worst enemies.

Vast emissions from energy production have overwhelmed the mechanisms that kept the level of carbon dioxide in our atmosphere relatively constant for a long time. Increasing levels are causing worldwide climate change.

Access to energy has become increasingly important, but more than a billion people are not attached to a power grid. Many of these "energy poor" are using inefficient, dirty, ad hoc methods to obtain electricity.

Flattening and crowding have led to destruction and disappearance of critical ecosystems. Species are disappearing at an alarming rate.

Because many people contend that human activity is not a major factor in climate change, Friedman addresses that issue -- first with a lot of science and then with a Pascal bet. The mathematician/philosopher Blaise Pascal argued that even though you might not be able to prove it, you should live as if God exists. Such a lifestyle, he contends, is intrinsically good, regardless of whether God exists or not. Applying this reasoning to climate change, Friedman says that changing our economy to use energy efficiently and to generate it from clean sources will benefit us greatly, even if "global warming" is a hoax. Of course, getting to that changed economy is not trivial, despite the proliferation of articles with titles like Seven Easy Ways to Save the Earth in Fifteen Minutes a Day. Friedman impresses us with the magnitude of the task.

The current level of carbon dioxide in the atmosphere is 270 parts per million (ppm). If human activity stops tomorrow, the level will continue to rise because of mechanisms already in motion. Friedman believes that a workable goal is to manage the unavoidable and avoid the unmanageable. He translates this into slowing the growth of the carbon dioxide level, so it reaches a maximum of less than 550 ppm around 2050. Robert Socolow and Stephen Pacala of Princeton University have computed the scale of the necessary programs, assuming that those programs start now and are completely in place by 2050. Some of their programs overlap or are alternate approaches. Here are some of the key programs:

For two billion automobiles, double the fuel efficiency to 60 miles per gallon, halve the number of miles per year to 5000, or change the fuel to ethanol or hydrogen.

For 800 to 1600 large coal-fired plants, sequester all of the carbon emissions, increase efficiency from the current 40% to 60%, or fuel them instead with natural gas.

Replace all coal-fired plants by generating twice as much energy as currently from nuclear plants, 40 times as much from wind, or 700 times as much from solar.

Cut by 25% the electricity used by homes, offices, and stores.

There are more, but these give an idea of the scale of the problem.

Friedman explains the current power distribution system. It is a loosely connected network (called a grid) of power companies (called utilities), all regulated by the states in which they operate. The utilities all participate in the following bargain: they can operate as monopolies as long as they provide a cheap, reliable, ubiquitous source of electrons. Unfortunately, the grid provides little support for the kind of innovations needed to reduce power use. The grid is huge, unintelligent, decentralized, unregulated, and poorly integrated. Its main defects are that it has no two-way communication, and there is no way to vary the price by load or time of day. Furthermore, the utilities operate under a business model that rewards them for generating and selling more power but not for promoting or facilitating efficiency. Friedman sees a smart grid and a new business model as essential to a sustainable energy system. The question is how to get there. Friedman's answer is to encourage innovation.

Near the bottom of page 243, Friedman buries the following:

If you take only one thing away from this book, take this: We are not going to regulate our way out of the problems of the Energy-Climate Era. We can only innovate our way out, and the only way to do that is to mobilize [the marketplace].

This is the essence of Friedman's proposal for replacing our current unsustainable energy system with a sustainable one: shape the marketplace so that this is the inevitable outcome, then let the free market system work. For those who don't consider this an example of a free market, Friedman has an answer: our current free market isn't free either. He points out that what he calls the fraudulent hiding of the true costs of resource extraction and consumption shapes the current market. In addition he cites regulatory anomalies like the difference in import tarrifs between Brazilian ethanol (54 cents per gallon) and Saudi Arabian crude oil (3 cents per gallon).

Friedman says that the market is like a garden to be shaped into an ecosystem for energy innovation. The shaping takes the form of an intelligently designed system of policies, tax incentives/disincentives, and regulations. He doesn't want to pick winners, but the entrenched interests are like kudzu. Uprooting them might be the hardest part of the job.

Friedman believes that the simplest way to shape the market is to provide a price signal, and he quotes from his interviews with the chief executive officers of General Electric and DuPont to support that view. A price signal can take many forms, but in essence it is a fixed target that developers of alternative energy sources can shoot at in their long term planning. To understand why this is important, consider the price of crude oil, which is largely controlled by a cartel, the Organization of Petroleum Exporting Countries (OPEC). The price tends to rise and fall by substantial amounts. Its rises stimulate development of alternative energy sources. Then it falls, and the companies developing the alternatives go out of business.

One price signal would be a government guarantee of a minimum gasoline price. For example, when gasoline prices exceeded $4.00 per gallon in the summer of 2008, the government could have said that for each dollar the price dropped, the tax would increase 95 cents. This would have told alternative fuel developers what price to shoot at. Instead, as autumn gasoline prices dropped to below half of the summer levels, alternative fuel developers were forced to change or abandon their plans.

Another kind of price signal, applicable to all energy production, not just vehicle fuel, is a carbon cap-and-trade regime. In this approach a controlling authority sets a limit on the total emissions of carbon from all sources in an upcoming time period. It then distributes individual limits to all possible emitters in the form of credits. The credits add up to the total emissions limit. Emitters who do not have enough credits to cover their emissions must buy them from someone else or pay a severe penalty. At the end of the covered time period, the authority sets a new, presumably lower, emissions limit for the next period and issues new credits accordingly.

An alternative to a cap-and-trade regime is a carbon tax. Emitters pay an amount that depends on the amount of carbon they emit. This is simpler than a cap-and-trade system. Each has advantages and disadvantages, which Friedman explores. Although the cap-and-trade system gives "environmental certainty" by limiting total emissions, Friedman prefers the carbon tax because it is more transparent.

A price signal that some countries (and Texas) already use is a renewable energy mandate. The controlling authority specifies a percentage of total power generation that must come from sources (for example, windmills or solar cells) that do not emit carbon. The authority then increases the percentage over time. European countries have done this to varying degrees, which is why the US company First Solar finds more business in Germany, Spain, France, Greece, and Portugal than in the United States.

Regardless of the form it takes, a price signal requires our leaders to make a long term commitment to a complex plan. This is why Friedman asks whether democracy can survive complexity. He envies the Chinese government's ability to dictate policies and have a reasonable expectation that all levels of the society will implement those policies. "If only we could be China for a day," he says, "but not for two days." In earlier crises, leaders took control to enable them to act decisively. Lincoln asserted power over the states, and Franklin Roosevelt expanded and strengthened the Federal government.

US energy policy, like our system of government, is designed to make inaction easy and transformational action hard. Among the cooks stirring this broth are state regulators, the Environmental Protection Agency, the Department of Transportation, the Department of Energy, the Department of Agriculture, the Army Corps of Engineers, and the Federal Energy Regulatory Commission. Friedman characterizes the resulting policy as follows: maximize demand, minimize domestic sources, and make up the difference by borrowing huge sums of money to pay to those who hate us. To centralize energy policy, Friedman proposes a real Department of Energy. He points out that the current department with that name is concerned mainly with watching over our nuclear weapons.

Friedman provides many success stories of green projects. For example, US troops in Iraq used diesel-powered generators to provide electricity for a remote desert base. Transporting diesel fuel to the base exposed them to the danger of attacks that were hard to defend against. By insulating their tents, they were able to reduce their air conditioning power needs to a level they could provide from wind and solar sources. They even had power left over to give to a nearby village. This example shows the power of a price signal. Considering the costs of transporting and defending shipments of diesel fuel, the Army found it easy to justify the costs of becoming energy self-sufficient.

Another example is the conversion of 7.5% of New York City's taxicabs to hybrid vehicles. This example shows the effects of regulation. The city had to remove regulations that forced taxis to be large and heavy. Moving forward from this success, New York is trying to achieve similar increases in the efficiency of limousines.

A main thesis of the book is that transforming our energy system is a key to remaining a world leader in the years to come. If we do not lead, other countries will, and we will fall behind. If other countries, particularly China, try to follow the same path we followed, we have little hope of averting catastrophic climate change. If we lead the way to a green revolution, other countries will follow, and we will remain a world leader. In other words, as Friedman puts it, green is the new red, white, and blue.

Friedman examines what is happening in China. As the world's most populous country and the one with the fastest growing economy, China is the key to successfully transforming our energy system. The Chinese government seems to have recognized the problem and committed themselves to producing cleaner energy, but they have competing priorities. The bargain between the Chinese government and the Chinese people is "we rule, and you rapidly become more prosperous." This means that they can't afford to stop the bus. They have to swap out the dirty engine and replace it with a clean one without slowing down.

This review focuses on a few key points, scratches the surface of others, and completely ignores parts of the book. Friedman is a thorough and careful reporter. As he showed in earlier books, he is good at understanding how issues interact. He tells compelling stories to illustrate his points. If you want to understand the workings of the worldwide energy system and how it interacts with population growth and climate change, you should study this book.

Effective Java, Thoughtworks Anthology, Javascript: The Good Parts

2008-10-26T20:03:00.000-07:00

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 the 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

2008-04-25T20:22:00.000-07:00

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

2007-12-15T17:32:00.000-08:00

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

2007-08-26T20:37:00.000-07:00

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

2007-04-15T23:21:00.000-07:00

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)

Invisible Engines, Making globalization Work

2007-02-14T12:18:00.000-08:00

Economics

This time I write about two books by economists. The first looks at the economics and winning business strategies of industries that require software platforms. The second addresses globalization.

Invisible Engines -- How Software Platforms Drive Innovation and Transform Industries by David S. Evans, Andrei Hagiu, and Richard Schmalensee (MIT, Cambridge, MA, 2006, 395pp, ISBN 0-262-05085-4, www.mitpress.mit.edu, $34.95)

The authors are experts who consult regularly with leading platform-based businesses. Evans and Schmalensee have advised Microsoft for many years, particularly about Microsoft's antitrust difficulties. Hagiu wrote a doctoral dissertation on two-sided economies -- situations in which two groups must participate (for example, auctions, which need both buyers and sellers).

In this book the authors lay out the underlying principles and parallels of personal computers, mobile phones, video games, online auctions, search engines, and similar industries. All of these have in common that they have more than one "side." For example, the Microsoft Windows operating system creates an ecosystem of hardware manufacturers, application developers, and end users.

The various sides in the ecosystem that a software platform creates depend on each other in various ways. Hardware manufacturers need software support to maximize their performance/price ratios. Hardware manufacturers and developers need buyers for their products, while the existence of desirable products on a platform leads to more buyers. These are the well known network effects that cause some platform ecosystems to grow rapidly while others shrink and die.

The interdependence of the sides in a platform-based ecosystem is commonplace knowledge. This book, however, goes into the details. It provides brief histories of various platforms and shows how their business and pricing strategies evolved.

The authors find that in each platform ecosystem, one side gets a better deal than the others. For example, in the Windows ecosystem, developers receive valuable tools and support for minimal cost, while buyers of Windows-based computers and software provide most of Microsoft's profits. In the video game business, on the other hand, users receive the game platforms at highly favorable prices, and the platform makers receive most of their profit from game developers. Media players (for example, Real Player or Apple Quicktime) are always free to end users, while the developers of the player software obtain their profits from content developers and distributors.

The book delves into pricing issues such as price discrimination, bundling, and charging for access versus charging for usage. The authors find, sadly, that it almost always pays the manufacturer to bundle features together, even though most buyers won't use most of what they buy. This leads to a kind of Moore's Law of software bloat: software platforms double in size roughly every two years.

The access versus usage question arises most notably in communication platforms like phones or personal digital assistants (PDAs). In theory, platform providers should charge for both, but in practice they usually charge for just one.

Interestingly, an industry rarely changes its pricing strategy as it matures. It tends to stick with the model that made it successful. An industry does, however, change its integration strategy. New platforms usually provide all sides of the ecosystem, because the network effects have not yet occurred. Later, as the ecosystem grows, the provider defines application programming interfaces (APIs) to allow outside vendors to supply alternatives to the platform provider's offerings. Microsoft Windows, for example, defines many standards to allow computer and peripheral makers, application developers, and even browser makers to complement each other's offerings. The Apple media delivery system, on the other hand, works best when all of the components (iTunes, iPod, the Apple music store, and the associated digital rights management software) come from Apple. Apple buys and resells content for this system.

As the authors discuss one platform after another, they repeatedly stress the importance of APIs and other standards that allow different sides of the platform ecosystem to innovate without entanglement with other players. We all know this, but it is interesting and useful to see the principle at work in many different platform ecologies.

The best thing about this book is the concrete detail. While the authors work hard to show the similarities between different platform-based businesses, their theories are not a procrustean bed. They discuss the quirks and odd corners of each industry and show how those quirks lead to the unique business strategies of that industry.

This is a valuable book for anyone who wants to understand or engage in a business based on a software platform. I recommend it highly.

Making Globalization Work by Joseph E. Stiglitz (Norton, New York, NY, 2006, 384pp, ISBN 0-393-06122-1, www.wwnorton.com, $26.95)

In The World Is Flat (Micro Review, May, 2005), New York Times columnist Tom Friedman emphasized the bright side of globalization. In Globalization and Its Discontents (Norton, 2002), Nobel Prize winning economist Joseph Stiglitz addressed the dark side of globalization. In his latest work, Stiglitz fuses these threads. He proposes ways to correct the problems he described in his earlier work, so everyone can benefit from globalization.

Joseph Stiglitz shared the 2001 Nobel Prize in Economic Sciences for his analysis of markets with asymmetric information. His research disproved many cherished assumptions that had persisted from the time of Adam Smith to the late twentieth century. In 1776, Adam Smith argued that free markets lead to efficient outcomes as if by an invisible hand. Starting with his field work in Kenya in 1969, Stiglitz accumulated the insights that led him finally to the conclusion that the invisible hand, if it ever existed, had disappeared. In its place, Stiglitz argues, government has a role in keeping free markets working. For example, free markets naturally lead to rapid flows of speculative capital into and out of developing countries. Institutions and regulations must protect those countries from the resulting instability.

By the time he received his Nobel Prize, Stiglitz had put his ideas into practice. He served as chair of President Clinton's Council of Economic Advisors, then as Chief Economist of the World Bank. While at the World Bank, Stiglitz went to war against the policies of the International Monetary Fund (IMF) and its chief supporter and shareholder, the United States Treasury Department.

Stiglitz's 2002 book Globalization and Its Discontents contends that IMF policies favored United States financial interests, while short-changing the poor nations that the IMF is supposed to help. That book was widely influential, especially after huge protests against globalization like the one at the Seattle World Trade Organization meeting in November, 1999. The book identified many problems and suggested some changes, but it didn't offer a comprehensive solution. Four years later, Stiglitz continues the story of the adverse effects of globalization, but also offers solutions to many of the problems he sees.

Stiglitz summarizes the main complaints against the current implementation of globlization:

The rules favor the industrialized countries. The rules are so unfair that the poorest countries are worse off.
Material values are more important than the environment or even life itself.
Developing countries lose sovereignty over decisions that affect their citizens' welfare, thereby undermining democracy.
There are many losers in both developed and developing countries.
Developing countries must accept Americanization of their economies and their culture.

An issue that exemplifies several of these points is especially relevant to technology-based industries. The protection of intellectual property ensures that those who invest their time and money in writing books or developing inventions receive a reward for their efforts. Granting a time-limited monopoly to creators encourages innovation and helps to expand the body of knowledge.

In recent years, however, United States laws about intellectual property have become a drag on innovation in the software industry. In the drug industry, patent laws favor the development of minor variations of high-volume drugs rather than cures for "orphan" illnesses with low potential sales. They also keep life saving drugs out of the hands of people who need them but can't afford to pay.

In 1993, bypassing the existing World Intellectual Property Organization, the World Trade Organization adopted the TRIPs agreement (for trade-related intellectual property). This subjected developing countries to even more onerous intellectual property restrictions. The most well known example is the fight over the right of countries with high incidences of HIV AIDS to manufacture generic versions of expensive drugs for that disease. More humorous examples are attempts to enforce western patents on traditional Chinese medicine or on the medicinal use of turmeric in India.

I never advocate any particular political point of view in this column. Globalization, however, is inherently political. In laying out his program to address the problems of globalization, Stiglitz makes many statements that others might regard as politically biased. Nonetheless, Stiglitz presents a compelling, comprehensive case for his program. Like Thomas Jefferson, he believes that an informed electorate that is willing to hold its leaders accountable can solve problems like those of globalization. He hopes to help today's voters and leaders understand the issues that globalization has raised.

I won't go into Stiglitz's views further here. I recommend that you read his book for the details of his analysis and his solutions.

Miscellaneous Books

2006-10-24T21:00:00.000-07:00

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:

An interface's implementation will do what its methods say it does.
An interface implementation shall do no harm.
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

2006-08-17T16:44:00.000-07:00

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.

The Singularity is Near, My Job Went to India

2006-02-21T20:58:00.000-08:00

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.