Seek and Show

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

Data, information, knowledge, content -- whatever you call it, there is more of it than any of us can keep track of. The volume continues to increase, and the tools for managing it don't keep pace with that growth.

Most people, however, don't even use the existing tools effectively. In The Pragmatic Programmer (Micro Review Jan/Feb 2000), Andrew Hunt and David Thomas admonish you to become an expert on using your tools. Their main example of this is a programmer's text editor, but it might apply equally well to Google, Adobe PDF, or Microsoft Excel. The books I look at this time show you how to get more out of tools that you probably already use every day. 

  

Online Search Tools

One of the main ways to find individual nuggets in the vast sea of online information is to perform effective online searches. Search sites like Google and Yahoo receive millions of requests for information every day and provide useful results with astonishing speed. Most people with online access know how to use at least one of these sites, but few people know how to exploit their full power.

The books in this section help you to use search tools more effectively. The first focuses on Google and all of its features, many of which are unrelated to searching. The second focuses exclusively on searching, but discusses a broad range of search sites.

How to Do Everything with Google by Fritz Schneider, Nancy Blachman, and Eric Fredricksen (Osborne, Emeryville CA, 2004, 382pp, ISBN 0-07-223174-2, www.osborne.com, $24.99)

Nancy Blachman is president and founder of Variable Symbols, a company that specializes in consulting and training on technical software. She has written books and training materials about Mathematica (Micro Review, August 1991 and February 1992). She holds a BS in mathematics from the University of Birmingham in the UK, an MS in operations research from UC Berkeley, and an MS in computer science from Stanford, where she has taught for eight years. She is the creator of the Google Guide website (www.googleguide.com).

For this book, Blachman teams up with two Google software engineers to produce a comprehensive guide to using Google. Unlike Blachman's Google Guide website, this book does not go into the underlying technical details. It focuses almost completely on how to use the various features of Google. It does this with a large number of step-by-step procedures, examples, and screen shots.

Google is mainly a search tool, but it is much more besides. Everybody, including me, who looks at this book says something like "I had no idea Google could do that!" about some feature Blachman describes. I also found explanations of many features that I had noticed but never looked into. I'm much more likely to use those features now that I've read about them.

If you want to know everything about Google, read this book.

Google and Other Search Engines by Diane Poremsky (Peachpit, Berkeley CA, 2004, 376 pp, ISBN 0-321-24614-4, www.peachpit.com, $19.99)

This is another book in Peachpit's marvelous Visual Quickstart Guide series. Previous editions were written by Alfred and Emily Glossbrenner, but Diane Poremsky (www.poremsky.com), an expert on Microsoft software, has taken over. Peachpit provides no information about the reason for the change.

The cover of the book puts the word Google into much larger type than the rest of the title. This probably reflects the current huge interest in Google and its public offering of stock. It also reflects the fact that Google has indexed far more pages than any other search tool. Nonetheless, the book is not principally about Google. Its message is to use the right search tool for the job at hand, and that may not be Google. Poremsky provides detailed information about Alta Vista, MSN, Yahoo, Ask Jeeves, Excite, Lycos, and even AOL. Moreover, she explains the differences between these search tools, so you can choose the right one for the search at hand.

If you want to know how to perform online searches effectively, read this book.

PDF and Acrobat

Another widespread approach to handling information is the Adobe portable document format (PDF) and the Adobe Acrobat tools for managing documents in PDF format. All publishing applications and all Microsoft Office programs can generate PDF documents. Almost everyone who goes online encounters PDF documents and can view them within a browser.

Beyond what everyone knows, however, are enormously powerful and varied publishing, viewing, and searching capabilities. Most people who use PDF every day know very little about these capabilities. The books in this section seek to correct that situation. The first focuses on Adobe Acrobat. The second focuses on PDF.

Carl Young's Adobe Acrobat 6 -- Getting Professional Results from Your PDFs by Carl Young  (Osborne, Emeryville CA, 2004, 412pp, ISBN 0-07-223138-6, www.osborne.com, $34.99)

Carl Young is an Adobe certified expert in Acrobat and FrameMaker, as well as a certified technical trainer. Adobe selected him to run the first public Acrobat 6 training sessions at their worldwide launch of Acrobat 6. As eminent as Carl Young is, however, I heard about this book from someone even more eminent.

Shlomo Perets has specialized in online documentation applications since 1993. He trains technical communicators to get the most out of FrameMaker and Acrobat and the combination of these tools. Perets started his company, MicroType (www.microtype.com) in 1989 to train and consult about electronic publishing tools and techniques. Based in Israel, Perets often comes to the United States on business. In June 2004, I saw him speak at the Berkeley chapter of the Society for Technical Communication (STC), where he presented a good deal of useful information about using Adobe Acrobat. Perets served as technical editor for Young's book, so perhaps his recommendation is not entirely unbiased. Nonetheless, Perets recommends Young's book as the best book to read about Acrobat 6.

Acrobat 6 has many powerful features, but its maddening user interface and its arcane options and settings make it opaque to most users. Futhermore, it is easy to produce a PDF that has mysterious flaws. For example, you may make a beautiful PDF document, but when someone else views it, it looks bizarre, because all the fonts have changed. Or the PDF may look right on screen, but the graphics look terrible when you print the document.

These problems and many more arise because users do not understand the consequences of their choices. Young explains how to make choices that lead to PDFs that behave the way you expect them to.

Once you understand the basics, you can try adding movies or sound. You can make your documents accessible to people with disabilities. You can investigate automation, reviewing tools, forms, digital signatures, differing access permissions, and many other advanced features.

To understand everything that Acrobat can do to make publishing, reading, and reviewing PDF documents go smoothly, read this book.

PDF Hacks -- 100 Industrial Strength Tips & Tools by Sid Steward (O'Reilly, Sebastopol CA, 2004, 296pp, ISBN 0-596-00655-1, www.oreilly.com, $24.95)

The O'Reilly Hacks series focuses on enabling clever programmers to customize software applications in ways the inventors of those applications never envisioned, or at least never publicized. O'Reilly has tried to reclaim the positive connotations that the term hacker had before it came to mean computer criminal. Hacks are clever, quick-and-dirty solutions to small problems. 

According to the book's publicity, Sid Steward has analyzed, extended, secured, cracked, authored, converted, embellished and consumed PDF over the last 5 years. He maintained and created custom software. He has pushed the envelope of Acrobat API programming. He has developed a toolset that is the core of a PDF conversion service bureau. He also performs PDF finishing, which includes optimizing PDF file size and adding navigation features.

This book is not about Adobe Acrobat, though Steward does provide some tools and tricks that apply to Acrobat. PDF adheres to a published specification, so anyone can process it. The Macintosh operating system has tools to process PDF. So does Ghostscript (www.cs.wisc.edu/~ghost).

I use Acrobat all the time, so my favorite hacks apply to Acrobat. For example, Steward shows how to shorten the time Acrobat takes to start, by disabling plugins that you are not likely to use. He also shows how to let Acrobat 6 use the important Acrobat 5 TAPS plugin, which Adobe does not provide with Acrobat 6. TAPS allows you to copy tables and other formatted text from PDF documents and paste them into other documents. This bit of information alone is worth the price of the book.

If you use PDF and like to tinker with your tools, this book is for you.

Attacking Complexity

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

For as long as I have been in the computer industry, increasing complexity has been a constant problem. Every advance in computer speed and storage capacity has been met by increased requirements and expectations for the software that runs on those computers. Moore's Law continues to bail us out, but it does not encourage efficiency. 

Efficiency is not a problem if we simply trade inexpensive hardware for expensive development time. Bloated and inefficient code and cumbersome development methodologies cause few problems for products that provide basic functionality with minimal demands on computing resources. Inefficiency becomes a problem at the cutting edge, when we try to squeeze out that last bit of added functionality to gain commercial advantage over our competitors.

This time I look at three books. One book shows how to apply the techniques of agile software development to projects of large size and scope. Another explains the ins and outs of an operating system that might be a little simpler than the one you're currently using. The third provides principles and techniques for simplifying Java application programs.

Agile Software Development in the Large -- Diving into the Deep by Jutta Eckstein (Dorset, NY, 2004, 246pp, ISBN 0-932633-57-9, www.dorsethouse.com, $39.95)

Since reviewing Extreme Programming Explained (Micro Review, Nov-Dec 1999), I have often written about agile software development techniques. Extreme Programming is the most famous of these techniques. Some others are Scrum, Crystal Methodologies, Feature Driven Development, and Adaptive Software Development. The proponents of these and other techniques have banded together into the Agile Alliance (www.agilealliance.org). The alliance has agreed upon a set of choices and a set of principles, known collectively as the Agile Manifesto.

Their basic choices are to value:

• Individuals and interactions over processes and tools.
  
• Working software over comprehensive documentation. 
  
• Customer collaboration over contract negotiation. 
  
• Responding to change over following a plan.

You can find the agile principles that flow from these choices expressed in twelve short paragraphs on the Agile Alliance website.

Many firms have tried to adopt or adapt agile techniques. Many of these attempts simply entail calling their existing processes agile or adopting a few superficial aspects of Extreme Programming. Other firms have seized on the second value choice as an excuse to eliminate documentation or to stop commenting code.

Such superficial or misguided attempts to use agile techniques have little practical benefit. Other attempts, however, have been successful, but almost always in projects of relatively small scale. The techniques described in most books on agile development do not apply easily to large projects. For example, using Extreme Programming on a large project might entail placing 100 people in a single room. This is likely to be impractical for most projects.

Jutta Eckstein is a member of the board of Agile Alliance and a software development consultant. In this book she shows  that there are practical ways to adapt agile development techniques to projects of large scale. As you might expect, these adaptations rely heavily on good project communication and on finding ways to assign tasks to small subteams.

Eckstein proceeds methodically through the aspects of agile processes that work differently in large projects. She brings the benefit of her real world experience to these questions. If you work on large projects, you'll find it well worth your time to read this short book.

How Linux Works -- What Every Superuser Should Know by Brian Ward (No Starch, San Francisco, CA, 2004, 366pp, ISBN 1-59327-035-6, www.nostarch.com, $37.95)

Unix in its many forms has been around for about thirty-five years. When it was half that age , I reviewed Maurice Bach's The Design of the Unix Operating System (Micro Review, Sept/Oct 1987). In the same column I reviewed Douglas Comer's book Operating Systems Design, The XINU Approach. XINU is a recursive acronym that stands for "Xinu is not Unix." It is also Unix spelled backwards. 

Xinu is one of many attempts to simplify and reinvent Unix, wholly or in part. Linux is the most successful of these attempts. It began in late 1991 as the work of Linus Torvald, and has grown into a poster child for open source development. Linux is the base operating system for many production web servers.

Brian Ward has been working with Linux since 1993. In this book he tries to give you an understanding of the inner workings of Linux. Rather than providing procedures for common Linux tasks, Ward provides conceptual information. He hopes that after you read his book, you can read and understand the documentation of any system program.

One interesting part of the book is Ward's explanation of the boot process. If you've ever watched a Unix system start up, you know that screen after screen of information goes scrolling by. In about ten pages, Ward explains what all of that information is meant to tell you.

Because Linux is frequently the base operating system for web servers, Linux administrators must understand networking and firewalls. Ward explains how these features work.

Operating systems must often support software developed by third parties. For example, in Windows, the .NET framework provides a way to encapsulate applications and avoid the DLL hell of earlier Windows systems. Shared libraries provide support for third party software in Linux. Ward shows how to manage -- and avoid the pitfalls of -- shared libraries.

One of the most powerful features of any Unix system is the programmable command shell. Many books explain how to use different shells. Ward gives a clear account of the basics of using the Bourne shell.

Ward addresses all of the main tasks that Linux administrators must face, but this book is not for current Linux administrators. They already know all of this and more. But if you have little experience with Unix and you want to set up a Linux system -- possibly on an old computer that can no longer run the latest Windows version -- this book is essential reading. You'll probably find the chapter on hardware especially useful.

Better, Faster, Lighter Java by Bruce A Tate & Justin Gehtland (O'Reilly, Sebastopol, CA, 2004, 262pp, ISBN 0-596-00676-4, www.oreilly.com, $34.95)

Tate and Gehtland are well known authors of books on software development. In this book they attack the current state of Java development, which they characterize as follows:

Development is getting so cumbersome and complex that it's threatening to collapse under its own weight. Typical applications use too many design patterns, too much XML, and too many Enterprise JavaBeans.

This is not,as you might have expected from the title, a book about improving your personal coding habits. Its main approach to producing better, faster, lighter Java applications may require you to change things that you do not control. Specifically, the authors ask you to consider abandoning heavyweight frameworks like WebLogic, Jboss, and WebSphere in favor of lightweight open source architectures like Hibernate and Spring. If such decisions are outside your control, you probably don't need to read this book. But even if you can't follow the book's advice, you may still find it enlightening.

The authors begin by painting a bleak picture of creeping bloat, though their principal target seems to be container managed Enterprise JavaBeans. They then enunciate basic principles that few are likely to disagree with:

• Keep It Simple.
  
• Do One Thing, and Do It Well.
  
• Strive for Transparency.
  
• Allow for Extension.
  
• You Are What You Eat.

These are understandable enough, except for the last. In that one, the authors appear to mean that you shouldn't swallow every bit of conventional wisdom and vendor hype that comes your way. Instead they want you to be a heretic -- challenge a few things that "everybody knows."

From this point, the plan of the book is clear: discuss the selection of underlying technology in the light of each of the basic principles. Then introduce Hibernate and Spring. Finally, develop actual applications.

The authors have a lot to say, and they are fighting a good fight. It won't take you a long time to read this book, and you might learn something important.

Dvorak Predicted

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

This time I look at a ten year old book of predictions about the computer industry. Most of the predictions are wrong to some degree, yet the book provides a valuable look at a pivotal time in our industry.

Dvorak Predicts -- An Insider's Look at the Computer Industry by John C. Dvorak (Osborne McGraw Hill, Berkeley CA, 1994, 184pp, ISBN 0-07-881981-4, $16.95)

I met John Dvorak in the early 1980s. I don't think we've talked since then, but I've caught many of his radio and TV programs. I think we met at a reception put on by Media Alliance. In a room full of writers enjoying the late afternoon view of the San Francisco Bay and chatting, over drinks, about all manner of subjects, we were the only two who wrote about computers. It's amazing to compare that image with the jostling throngs of computer media representatives queued up to enter the hall for a Bill Gates or Steve Jobs keynote today.

In 1994, when this book appeared, Dvorak had been in the computer business as an entrepreneur, and then as a writer, for nearly twenty years. He had immersed himself in the computer industry. His columns dealt with nuts and bolts issues about computers, peripherals, storage media, firmware, operating systems, development tools, word processors, spreadsheets, and anything else you might think of. 

Dvorak's book is out of print now, but I found copies on the Internet for 80 cents and up. After all, who wants a ten year old book of predictions about the computer industry? The title is deceptive, though. Dvorak makes many predictions, but he also brings in a good deal of history and analysis to support them. Reading this book provides a fascinating look back at an important time in the history of our industry.

In 1994 practically nobody had heard of browsers and the web. The closest approximation to a website was a bulletin board system (BBS). The Java language had not yet sprung into prominence, and the closest approximation to "write once, run anywhere" was software or hardware emulation of the Intel 486 microprocessor. Online pornography was in its infancy, and junk email was a minor nuisance. Broadband to the home was a thing of the future, though a few people were using ISDN connections. Hardly anybody remained connected all the time. Most people dialed up their service providers when they wanted their mail. Even though Robert Morris's worm in 1988 had spawned the virus epidemic, malicious attachments were few and easily avoided. Rapidly spreading viruses and continually updated virus protection software were rare.

Dvorak does not mention Java, browsers, the World Wide Web, or spam. It's unfair to expect complete prescience, though. His analysis and some of his predictions capture the spirit, if not the details, of many developments that he did not complely foresee. He predicts a few things that have definitely not come to pass, but by and large, his predictions are good. In fact, the worst thing about the book is the many correct predictions he makes about things that do not matter at all ten years later. I think this points up the most problematic point about reading predictions -- it's rarely clear how to act to take advantage of them.

Though Dvorak didn't see the web coming, he saw something similar in his analysis of other people's predictions of 500 interactive TV channels. He said

It won't be 500 channels. It will be 50,000 or more channels all individually pumped out of homes and businesses in much the same way as computer bulletin  boards work today.

 . . . We can assume that people might just put a camera in their dining room, allowing us to watch a  family eat and argue.

He imagined that this might be implemented using BBS technology, with people dialing up over ISDN. From this he extrapolated to an amazingly prescient prediction.

Dvorak predicted that "Little brother will be watching, and little brother will be everywhere." From videotape of the Rodney King beating in 1992, to Amy Goodman's trickle-up journalism, to recent photographs of the coffins of war dead, we see how Big Brother cannot control the content of the news.

In 1994, Dvorak grudgingly conceded that we would have to take windowing seriously and that command line interfaces would die out. He felt that Unix, despite a nifty graphical user interface (motif), would nonetheless remain a niche operating system. He did not foresee Linux and the whole open source movement, though he did consider the possibility that the Public Windows Interface, as proposed by Sun Microsystems, might help keep Microsoft from building obstacles to competing products into its operating systems ("DOS isn't done until Lotus won't run").

Dvorak felt that Microsoft would try to achieve a monopoly in the industry. In 1994 it was not obvious that this could happen. IBM was still in the picture with OS/2. Apple was continuing to grow and was looking forward to a future based on the PowerPC architecture. WordPerfect was a popular competitor to Microsoft Word. Windows for Workgroups and its successors had not yet shown that they could push Novell from its network dominance. In fact, Dvorak believed that if Novell gave away DR DOS 6.0 to the entire industry, it could seriously undercut Microsoft. Novell did not do this, of course, so there is no way to know how effective that action would have been.

Dvorak also predicted that Microsoft would open a chain of software stores, so it could control both the shelf space and the sales pitch. This did not happen, of course, but that may be largely because Microsoft achieved those goals through other means. In the 1960s, IBM was amazingly successful at selling to data processing (DP) managers, which gave IBM market dominance at that time. IBM was a safe buy, so why risk anything else? Today's equivalent of the DP manager is the information technology (IT) manager, and Microsoft can reach them with a similar argument about networked Windows machines. On this basis Dvorak concluded that Macintosh sales to business would fall off drastically.

Dvorak's predictions of Microsoft's future were not all rosy. He said "Microsoft's domination will come to an abrupt end." He didn't say when, so he could still be right, but ten years later, there's no sign that this will happen. Dvorak's reasoning is interesting, though. He saw Microsoft as a company of youngsters willing to work 70 hour weeks and take gratuitous abuse from the management, because the rising stock price kept turning them into millionaires. He reasoned that the stock price could not keep going up without a few dips and that nobody would put up with Microsoft working conditions without that incentive. On top of that he says

Lotus has reemerged as a leader in the spreadsheet arena and pretty much owns the groupware category. WordPerfect is spending all its extra money marketing its word processor. . . . The best development tool are now produced by Borland and others. . . . NT does  not look like it will be much of a success either as  a network server operating system or as a standalone  operating system.

Dvorak also believed that hiring "old pros" would hurt Microsoft by eroding the general naivete and diverting energy into corporate empire building games. 

Dvorak devotes a large portion of his book to the microprocessor wars. He had great hopes for the PowerPC architecture. I was the guest editor for the Micro issue on PowerPC (Sept/Oct 1994), so I remember quite well the enthusiasm that everyone felt at the time. That architecture has been a success, and Apple has successfully moved to it. Dvorak believed that IBM had a secret strategy to include a clone of the Intel 486 chip as part of a PowerPC chip. I don't recall whether IBM actually did this. In any event, PowerPC has done little to affect Intel's dominance.

It is a cliché of futurism that people tend to overestimate the short term impact and undersestimate the long term impact of new technologies. In 1994 Dvorak said that voice recognition would be the killer app of the 1990s and would take off explosively in the next two years. This prediction is probably correct for the long run, but it hasn't happened as fast as Dvorak predicted. Similarly, Dvorak predicted that the Unicode character encoding scheme would lead to the death of ASCII by 1995. ASCII is alive and well today, though Unicode has become increasingly important.

Dvorak predicted that virtual reality would be a dud and that the TV and the computer will not merge. Dvorak saw that the marketing hype of the time overestimated the short term impact of these technologies. I suspect that Dvorak underestimated their long term impact.

I could go on and on. This short book contains a great deal of material. If you are at all interested in how we got where we are today, you should find a copy of this book and read it.

Single Sourcing, Mount Fuji

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

This time I look at two books that have little in common. One provides a nuts and bolts account of how to approach a difficult real world problem. The other looks at the kinds of fanciful, artificial problems that interviewers at some high tech companies -- and their imitators -- pose to job applicants.

Single Sourcing -- Building Modular Documentation by Kurt Ament (William Andrew, Norwich NY, 2003, 246pp, www.williamandrew.com, ISBN 0-8155-1491-3, $33.95)

Single sourcing is a way to produce documentation so that you only have to write the meat of it once. You create a collection of modules, each of which says one thing well. Then you use those modules to publish the same information in many forms -- print and online, reference guides and training materials, English and Japanese, and so forth. At least, that's the theory. The devil is in the details. 

Kurt Ament is an information architect. He has used XML, and its predecessor, SGML, to produce single sourced documentation for Hewlett-Packard, Hughes Aircraft, Xerox, and other large companies. He has distilled the experience he gained from these jobs into a clear and concise guide to approaching large documentation projects. Others have written thick volumes on aspects of this problem. Ament does a better job in a lot less space by focusing on the key issues:

• structured information
  
• teamwork
  
• modular writing

He addresses these issues independently of the underlying technology, but his examples refer to popular tools.

There are many systematic techniques for producing structured information. Ament settles on a fairly simple one. If you are converting old documents into structured form, you can start by analyzing the information in the old documents. Otherwise you can start from scratch. In either case, Ament's taxonomy has two levels: primary modules and secondary modules. The primary modules are topics, processes, procedures, definition lists, and similar entities. The secondary modules are examples, figures, tables, notes, itemized lists, and entities of that sort. Ament's method calls for identifying, labeling, organizing, and producing these modules.

One step in producing structured information is to integrate the secondary modules into primary modules. Ament provides guidelines for this. Some types of secondary modules are inappropriate for some types of primary modules. Ament is particularly hard on tables. He wants to keep them out of most kinds of primary modules. In general, he finds them hard to work with when producing output in more than one format.

Another step is arranging modules into hierarchical documents. Ament recognizes that using a hierarchical structure helps writers ensure that their documents are comprehensive and coherent. Unfortunately, readers, especially online readers, have difficulty perceiving and navigating within a hierarchy. Ament recommends flattening the natural hierarchies of documents to make them more usable. This is much easier said than done, and Ament does not give much practical advice in this area.

Another important step is to design the linkages that underlie the navigational aids in the target output. These linkages take the form of tables of contents, indexes, and inter-module references. Doing this carefully is important for all documents, but especially those intended to be viewed online. Ament gives guidelines for these tasks, but he cannot teach you how to perform them. I understand that he has written a separate book on indexing, but I have not seen it.

Ament's process is ongoing. After you build and test the documents that embody your structured information, you look at the lessons learned and adjust your process. This is an important step in all projects, but it is especially important in single sourcing large document sets. Here success depends on having a process within which individual writers can work together to speak with a single voice.

The success of single sourcing projects depends heavily on teamwork. Individual writers must accommodate their personal writing styles to match the team voice.  Ament recommends that team members develop writing guidelines based on what works in actual projects and adopt these guidelines by unanimous consent. This limits the style guide to rules that everybody agrees to. People have difficulty following rules they don't believe in. If team members don't follow team rules, the team falls apart.

Ament suggests a division of labor within teams. He wants to centralize information architecture and distribute information development. These functions tend to have competing objectives, and the people who perform these functions have disparate viewpoints. As a result, Ament stresses the need for these groups to overcommunicate.

Ament devotes about half of this short book to what amounts to a sample style guide for a single sourcing team. The fact that he can write a style guide in 130 pages shows that he follows his own rules: he sticks to what works in actual projects, and he proposes rules that everybody is likely to agree with. This section is the heart of the book, because it addresses the difficult problems of writing modularly. Modular writing does not come naturally to most writers, but without it you cannot produce successful single sourcing projects.

Ament makes an interesting point: what works in print may not work online, but whatever works online usually works even better in print. Thus, his guidelines for modular writing come mostly from the needs and constraints of online documentation. 

For a documentation department planning a single sourcing project, this book is pure gold. Ament writes clearly and concisely. He brings real world experience to the most difficult issues and offers practical advice for addressing them. If your success depends on producing usable product documentation in a variety of forms, you must read this book.

How Would You Move Mount Fuji? -- Microsoft's Cult of the Puzzle by William Poundstone (Little Brown, Boston MA, 2003, 290pp, ISBN 0-316-91916-0, $22.95)

William Poundstone is a well known science writer. He has produced a thought provoking and highly entertaining book. The book is thought provoking because it examines a widespread practice, the posing of tricky and artificial logic puzzles to job applicants. It is entertaining because it includes many representative puzzles and because it pokes fun at Microsoft.

I have no personal bias either against or in favor of the Microsoft Corporation. I use their software every day. I enjoy its benefits, but often curse its faults. I have never interviewed for a job with Microsoft, so I have no idea how true or fair anything in this book is. Nonetheless, I thoroughly enjoyed reading it.

Poundstone describes Microsoft job interviews as a gauntlet, akin to fraternity hazing. He includes accounts of several actual interviews -- each quite funny and each resulting in "no hire." Microsoft has many more job applicants than open positions. Their principal objective in interviewing is to disqualify anyone they're not completely sure about.

Part of the hazing is to confront applicants with questions like "Count in base negative 2," "If you could remove any of the fifty U.S. states, which would it be?" or "How would you move Mount Fuji?" Other questions, however, are logic puzzles like finding the underweight billiard ball with a minimum number of weighings or determining how to get the missionaries and the cannibals across the river. The justification for asking questions of this variety usually begins with "It stands to reason that . . ." and asserts a correlation between the ability to solve such puzzles and future success writing computer programs. The degree of correlation is known in the testing business as the validity of the test. Even under controlled conditions, standardized IQ tests have questionable validity as predictors of any sort of job success. Logic puzzles, in the chaotic environment of a job interview have no established validity at all.

Even though questions of this sort have little value in job interviews, they have become increasingly popular in a wide range of industries. Companies try to emulate Microsoft -- either out of a wish to achieve similar success or because more traditional hiring approaches have become completely ineffective. Legal considerations have made obtaining useful information -- especially negative information -- from personal references difficult. Candidates come in with well rehearsed answers to traditional questions like "What's your greatest fault?" or "Where do you see yourself five years from now?" A question about the probability of dying in a game of Russian roulette adds a little spice to the process -- at least until all potential applicants have rehearsed answers to that question too.

While I have little interest in job interviews, I found the book fascinating. I enjoyed the opportunity to think of plausible answers to the impossible/stupid questions and to work out the logic puzzles. My ten year old daughter got a big kick out of the questions too. We spent a whole afternoon discussing the problems and reading some of Poundstone's answers. Then she went off to tell her mother how to move Mount Fuji.

Poundstone provides answers to the questions he mentions in the book. He also puts forth a few general rules for addressing this type of question. He frames the discussion in terms of how you should interact with the interviewer. 

Given the widespread nature of this interviewing technique, if you are looking for work, you should definitely read this book.

Me++

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

Janus, the god after whom January is named, has two faces. One looks forward, the other back. Recently, I've looked at some of my old columns, and thought again about the topics they cover. The book I focus on this time has its antecedents in earlier works by the same author. At the same time, it follows the Janus model by looking into the future without losing sight of the past.

Me++ -- The Cyborg Self and the Networked City by William J. Mitchell (MIT, Cambridge MA, 2003, 266pp, ISBN 0-262-13434-9, mitpress.mit.edu, $27.95)

William Mitchell is a professor of media arts and sciences at Massachusetts Institute of Technology (MIT), where he also serves as dean of the School of Architecture and Planning. Me++ is the most recent in a series of books that Mitchell has written about about the way that information technology is transforming our lives.

In the November/December 1995 Micro Review, I reviewed Mitchell's City of Bits -- Space, Place, and the Infobahn (MIT, 1995). In that book Mitchell uses vignettes from his personal experience to contrast scenes of the electronically mediated world with their classical counterparts. City of Bits is like an impressionist painting. Mitchell uses it to train your eye (and his own) to see the world in a different way.

The electronically mediated world has changed considerably since 1995, and MIT has reinvented City of Bits as http://mitpress2.mit.edu/e-books/City_of_Bits/, which claims to provide a graphically rich site, enchanced with over 200 links, a sophisticated search engine, and a unique public forum environment. The idea is intriguing, but the implementation appears to be poorly maintained. Most of its links were broken when I visited the site. Nonetheless, I found the entire text of City of Bits there, so you can read it online if you like. But if you'd like a hardcopy version of the book, the link to ordering information works perfectly.

In 1999 Mitchell brought out e-topia -- "Urban Life, Jim, But Not As We Know It" (MIT, 1999), a sequel to City of Bits. In that book Mitchell considers the ways in which architecture and urban planning must change to accommodate broader notions of place and proximity. Virtual places and electronically mediated interconnection provide new opportunities and constraints for architects and planners to work with. Mitchell paints an inviting, optimistic portrait of the resulting communities of the twenty-first century.

Mitchell's latest book continues the train of thought from City of Bits and e-topia, but this time he addresses the subject much more concretely than he did in City of Bits. One reason for this is that people have had time to integrate the world of bits into their physical worlds. The separation between bits and atoms, as described by Nicholas Negroponte in Being Digital (Knopf, 1995), has proved to be a trial separation. Bits and atoms are reconciled. The marriage is back on track. 

The term Me++ suggests a self, extended by portable wireless devices, moving about a networked world. Wireless phones or computers provide access to navigation aids and communication. MIT students bring laptops to class and use wireless internet connections to Google the lecture topic, making for a more intense and interactive learning experience.

Mitchell sees the Dilbert world -- that is, the 1990s workplace divided into cubicles containing PCs -- as dead. Any place can now be a workspace. This gives people another reason to be in public spaces, and it gives architects a chance to focus on reforming these spaces to accommodate the new functions. A café may need well lit seats with their backs to the wall to provide convenience and privacy for laptop users. It may need alcoves into which mobile phone users can go to converse without disturbing or being disturbed by others. Social conventions need to evolve around these new spaces and functions.

The city has always been a system of containers (city walls, buildings, rooms) and networks (transportation, energy supply, communication). To support the extended self, the containers become less physical, and the networks become more numerous and more important. Technological advances also change the nature of the infrastructure. The transportation and communication infrastructure of the twentieth century resulted from government investment or from private investment with government encouragement and support. Infrastructure like WiFi, on the other hand, comes from the bottom up.

One of Mitchell's main messages is that McLuhan's global village is really here. A community is a network of reciprocity. Traditionally, the associated social glue and moral obligations attenuate with distance. We feel most strongly obligated to our families, then to our communities and countries. In the past we felt little responsibility for people in distant lands. Nor did we feel that those distant people could have much effect on us. Events like those of September 11, 2001 show that this is not true. More mundane negative events, such as widespread power grid failures or virus attacks, underline the fact that we must take the idea of global community seriously.

The idea of a global village goes against many strongly held views. Networks and interconnections make boundaries permeable. They are incompatible with the view that nation states can close their borders or isolate themselves from the affairs of other nation states. On the personal level, the idea of "me first" must give way to a Golden Rule that acknowledges our interdependence.

Mitchell does not believe that nation states are doomed, but he does believe that physical places must emphasize the features that make them special. Distinctive subcultures, scenic beauty, desirable climate, and historic connections can all distinguish one place from another and help to perpetuate place-based communities. Physical place, Mitchell believes, will remain at the apex of a pyramid of different kinds of presence. Email may be excellent for routine communication. Synchronous communication by video and phone can satisfy the need for immediate feedback. But the most important situations call for two or more people to be in the same physical location at the same time.

Mitchell's chapter and section titles are filled with allusions. Titles like Virtual Campfires, Cyborg Agonistes, and Downsized Dry Goods reinforce the connections he sees among the electronically mediated world he describes, the world it is evolving out of, and the underlying culture that both worlds reflect. Mitchell sees many connections, and these add value to his work. One literature professor, quoted on the book jacket, says that Mitchell "is able to see the future without losing sight of the past, and he embodies the technological savvy yet still deeply humanistic perspective we need to understand where our technologies are leading us and where we should be leading them." She also praises the book's wittiness, urbanity, and wide range of reference. I agree with these assessments, but I wish Mitchell didn't carry it quite so far as he does.

I think Mitchell sometimes displays his erudition too consciously. Most readers, I suspect, will get little help from the references in the following excerpt:

It opens up the possibility of new, as yet unimagined spatial practices, and the opportunity (in the words of Michel de Certeau) "to rediscover, within an electronicized and computerized megalopolis, the 'art' of the hunters and rural folk of earlier days." Or, if you don't like the pseudo-primitivism of this formulation, you might imagine rediscovering Baudelaire's flânerie, situationist "drift," or whatever it was that Deleuze and Guattari were recommending in A Thousand Plateaus.

Along the same lines, the title of the book will not mystify programmers, but readers who don't get the allusion to the incrementation operator and to the C++ language will face an unnecessary obstacle to understanding what the book is about.

Mitchell's erudition extends to his vocabulary. I'm sure I knew the meaning of insouciant and carapace when I took the SAT exams, many years ago. Now when I encounter these words, however, I have to look them up. And as for enciente -- I'm sure this book is the first place I've ever seen it. Sometimes common words communicate better than uncommon ones, even at the expense of lost nuances.

These small annoyances aside, I think that Me++ is an essential read for anyone trying to make sense of the bewildering advances that are transforming our world. Reading it should take you only a few hours. Do it now. Janus would approve.

So Many Books, So Little Time

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

I try to write in depth reviews of a few worthy items in each column, but sometimes the flow overwhelms the system. Here are short reviews of some books I wish I had more time to examine.

General Interest

How the Internet Works, Seventh Edition by Preston Gralla (Que, Indianapolis IN, 2004, 368pp, ISBN 0-7897-2973-3, www.quepublishing.com, $29.99)

Preston Gralla is a well known technology columnist and author. In this large format book, lavishly illustrated by Michael Troller, Gralla explains all of the concepts that most people are likely to encounter in connecting to the Internet. The explanations are not deep, but they systematically cover the basics. Most people, even experts, will probably find at least some of the explanations helpful. For example, I feel that I know quite a bit about the Internet, but Gralla's explanation of proxy servers clarified the subject for me.

The illustrations are colorful and attractive, but in many cases they are merely decorative. Visual learners may find them helpful, though I doubt that anyone could get much from the book just by looking at the pictures. The text, on the other hand, can probably stand alone.

If you know someone who is just starting to use the Internet and email, consider giving them this book. It may save you from some difficult questions. 

Firewalls and Internet Security - Repelling the Wily Hacker, 2d ed by William Cheswick, Steven Bellovin & Aviel Rubin (Addison-Wesley, 2003, 456pp, ISBN 0-201-63466-X, www.wilyhacker.com, $49.99)

In the interest of full disclosure, I need to say that I know Bill Cheswick and have heard him speak on many occasions. He is a remarkably charming, inventive, enthusiastic, boyish person with a wonderful sense of humor. His personality comes through as you read the book.

The 1994 edition of this book quickly became the standard reference for security professionals. The long awaited new edition brings the work up to date. Some of the issues in the book are of interest only to security professionals, but many of us nowadays have home networks for which we have to provide the security ourselves. We rely on off the shelf virus protection and firewalls, but most of us have no idea how to provide effective security. This book can help.

One of the great strengths of this book is that anyone with a general knowledge of computers and the Internet can read most of it. The Security Truisms section at the start of the book contains aphorisms like An attacker does not go through security, but around it. Sun Tzu could have written this 2500 years ago.

If you read this book, you'll come out knowing a great deal about security, and you'll have fun doing it. 

Windows XP Hacks - 100 Industrial Strength Tips and Tools by Preston Gralla (O'Reilly, Sebastopol CA, 2003, 412pp, ISBN 0-596-00511-3, www.oreilly.com, $24.95)

Preston Gralla has apparently been busy! In addition to figuring out how the Internet works, he has assembled a useful collection of ways to make Windows XP behave better. The O'Reilly Hacks series (and the associated site, hacks.oreilly.com) uses tools, configuration options, and even unpublicized registry settings to make your life easier. This book tells you how to get your old programs to run under XP, even if they are nominally incompatible with XP. It tells you where to find free tools to convert files from one graphics format to another. It helps you remove unwanted icons from your desktop. It provides strategies for reducing spam.

I love books like this. I don't think it is as thorough or detailed as Windows XP Annoyances (Micro Review, Jan/Feb 2003), but it's worth looking at.

From Gutenberg to the Global Information Infrastructure by Christine L. Borgman (MIT, Cambridge MA, 2003, 344p, ISBN 0-262-52345-0, mitpress.mit.edu, $21.95)

This book is a paperback reissue of a work that won the 2001 Best Book Award from the American Society for Information Science and Technology. Borgman looks at how well the global information infrastructure does, or might in the future, fit into our daily lives. She views this as the main criterion of its success.

Though Borgman comes to the subject from a background in information studies, she takes a holistic approach that considers sociological factors as well as technical and implementation details. She views digital libraries, electronic publishing, and the life cycle of electronic information in terms of their effects on humans.  

Borgman's presentation is in the academic style, with many references and a dry, impersonal voice. Nonetheless, it is not difficult reading. It provides a valuable and nuanced perspective on a technology that most people see in black and white. If you have not thought much about the human consequences of the global information infrastructure, Borgman's book is a good place to start.

Adobe Acrobat 6.0 Standard Classroom in a Book by Adobe Creative Team (Peachpit, Berkeley CA, 2004, 456pp plus CD, ISBN 0-321-19374-1, www.peachpit.com, $45.00

The Adobe Classroom in a Book series has a well deserved reputation for being thorough, accurate, easy to use tutorials. Adobe Acrobat 6.0 Standard is the latest version of Adobe Acrobat software. I haven't had a chance to look at Acrobat 6 in detail, but it seems to be a lot like Acrobat 5.

If you are new to Acrobat, this tutorial is an excellent way to cover all of the main features in a thorough and authoritative way.

Open Source

Tomcat - The Definitive Guide by Jason Brittain & Ian F Darwin (O'Reilly, Sebastopol CA, 2003, 412pp, ISBN 0-596-00318-8, www.oreilly.com, $39.95)

Tomcat began life as part of the Sun Microsystems development kit for JSP and servlets. A few years ago Sun donated Tomcat to the Apache Foundation, where it became an open source product. It is the most widely used platform for JSP and servlets. If you are going to develop J2EE web applications, you will probably use Tomcat.

This book tells you everything you need to know about the theory and the details of all of the Tomcat features you're likely to use, including security.

Code Reading - The Open Source Perspective by Diomidis Spinellis (Addison-Wesley, Boston MA, 2003, 526pp plus CD, ISBN 0-201-79940-5, www.awprofessional.com, $49.99)

This book has a simple premise. Programmers need to be able to read code. There are two main reasons for this. The first is to help learn how to write good code. As with prose writers, reading excellent examples of others' works helps programmers find their own voice and develop their own excellent styles.

The second reason to learn to read code is to be able to modify or augment existing programs. Programmers spend large portions of their lives in just such activities.

Spinellis notes that the open source movement has made a great deal of excellent code available. His book uses this resource to help you become a good code reader and writer. Using numerous examples from actual code, Spinellis discusses a wide variety of programming topics. In the end he has written a computer science textbook with all of the examples taken from real life.

PHP and MySQL for Dynamic Web Sites Visual QuickPro Guide by Larry Ullman (Peachpit, Berkeley CA, 2003, 590pp, ISBN 0-321-18648-6, www.peachpit.com, $24.99

Because they are open source products and are widely available, PHP and MySQL are widely used tools for server side scripting and database access for personal or small business websites. Ullman systematically covers all of the tasks a web developer might wish to perform and presents procedures for them, with complete code examples and visual representations of screens and output.

The Peachpit visual guides are all very well done, and this one fits right into that mold. If you're developing a website with any sort of server side component, you should read this book.

 

Extreme Programming With Ant by Glenn Niemeyer & Jeremy Poteet  (Sams, Indianapolis IA, 2003, 456pp plus CD, ISBN 0-672-32562-4, www.samspublishing.com, $34.99)

I have reviewed many books on extreme programming (XP) in this column over the years. For example, I reviewed Kent Beck's Extreme Programming Explained in the Nov/Dec 1999 Micro Review. Beck is essentially the inventor of XP, and his book explains its principles and the reasons behind them.

Ant is an open source extensible scripting language that many people use to automate processes for building and deploying software. XP relies on automated testing and frequent builds, so Ant is an ideal tool. The authors show how to use Ant to automate testing and builds, but that's just the beginning.

XP relies on coding standards, because everybody is always free to change any code at any time. Without standards, chaos would reign. Ant can help to enforce standards. Similarly, the authors proceed to automate every aspect of the XP development cycle.

If you're doing XP, or if you just want some good ideas for how to use Ant to help with whatever development process you follow, check out this book. 

Java and JSP

The next two books total close to 2400 pages. They are part of a series for developers. If you know everything in them, you should have no trouble developing enterprise applications, including web services, in Java.

J2EE Developer's Handbook by Paul J. Perrone, Venkata Chaganti & Tom Schwenk (Sams, Indianapolis IA, 2003, 1536pp plus CD, ISBN 0-672-32348-6, www.developers-library.com, $59.99)

The authors spell out their mission right away: 

Provide a comprehensive, cohesive, and practical guide for building scalable, secure, assured, Web-enabled, and distributed enterprise systems with the Java 2 Platform, Enterprise Edition (J2EE). The technologies presented in this book can be used to rapidly build any enterprise system and integration solution that you can imagine. We describe these enterprise technologies from the ground up, leaving you with a thorough and in depth understanding of the Java enterprise application stack.

That's a pretty tall order, but from what I can tell (I haven't read every word), they do a pretty good job. Nonetheless, if you finish the sections on application servers, servlets, JSP, and web services (about 200 pages) and you still haven't had enough, you can read the next book.

JavaServer Pages Developer's Handbook by Nick Todd & Mark Szolkowski (Sams, Indianapolis IA, 2003, 838pp, ISBN 0-672-32438-5, www.developers-library.com, $49.99)

JavaServer Pages (JSP) is a way of enhancing HTML with server side Java code to make web pages more interactive and to help them deliver access to databases and other server capabilities. If you don't really need to understand the entire J2EE architecture, this book can provide everything you need to know about JSP. The book contains a huge amount of sample code, which you can download from the book's website. 

.NET

Measured by weight or by number of pages, the two books in the Java and JSP section beat the two in this section by about two to one. Nonetheless, these two can hold their own.

Microsoft's .NET is relatively new and corresponds approximately to J2EE. The ASP.NET facility corresponds approximately to JSP.

.NET Framework Essentials by Thuan Thai and Hoang Q. Lam (O'Reilly, Sebastopol CA, 2003, 380pp, ISBN 0-596-00505-9, www.oreilly.com, $29.95)

The .NET framework is the basis for all new Windows development. In it Microsoft responds to the major trends of the last few years: distributed computing, component based development, enterprise services, and sharing of functionality across the web. It also responds to the maturity of information technology, which creates an expectation of interoperability, scalability, availability, security and manageability.

The .NET common language runtime (CLR) is analogous to a Java virtual machine (JVM), but there are important differences. Rather than the interpreted bytecodes of the JVM, the CLR works with compiled code. All languages compile into the same object format, use a common library, and interoperate. This means that methods written in different languages can inherit from each other, catch each other's exceptions, and so forth.

The .NET framework eliminates the notorious DLL Hell by drastically reducing the reliance on registry entries and by not using file names to bind programs together. For many programs (not all), you can install them by copying their files to the disk and uninstall them by deleting the files.

This book describes these and many other features of the .NET framework in enough detail for you to feel comfortable using them. It gives you a sufficient overview to make it easy for you to use more detailed reference works.  

ASP.NET in a Nutshell by G. Andrew Duthie and Matthew MacDonald (O'Reilly, Sebastopol CA, 2003, 998pp, ISBN 0-596-00520-2, www.oreilly.com, $44.95)

While the previous book provides a detailed overview, this one gets right down to the nitty gritty. If you are familiar with O'Reilly books in the Nutshell series, you know what to expect with this one. It provides a small amount of overview information, but a great deal of detail about the properties, methods, and events of the main ASP.NET classes. The format of the book and the detailed table of contents and index make it easy to find what you're looking for.

Waltzing with Bears, Lean Software Development

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

Managing Software Projects

This time I look at two books on software project management. One addresses a gap in current standard methologies. The other provides a toolkit for a new kind of software development -- one that has grown in popularity in recent years.

Waltzing With Bears -- Managing Risk on Software Projects by Tom DeMarco & Timothy Lister (Dorset House, New York NY, 2003, 208pp, ISBN 0-932633-60-9, www.dorsethouse.com, $33.45)

Dorset House Publishing seems to have found a great formula, and I hope they stick to it. In recent years they have produced a steady stream of books with the following charactersitics:

• Short - generally well under 300 small format pages.
  
• Packed with practical advice on software project  management.
  
• Written by people who have been managing software development successfully for a long time.
  
• Iconoclastic - often showing common practices and beliefs to be short sighted, counterproductive, and generally absurd.

This formula works because of the "software crisis" that the industry has been bemoaning for at least 35 years. Software project management, as practiced by the mainstream of the industry, has not advanced significantly during that period. Relational databases, object-oriented design, and powerful development tools have made individual programmers vastly more productive, but project management has not gone far beyond where it was in the 1960s.   

As I noted in my review of DeMarco's novel The Deadline (Micro Review, May/Jun 2000), I was inspired by his Structured Analysis and System Specification when I first read it in 1979, and time has improved his understanding. DeMarco and Lister are long time partners in a consulting firm that specializes in software management issues. They have lectured and written extensively about corporate culture, management, productivity, estimation, and risk.

Managing risk receives more lip service and less real effort than any other issue in software project management. In fact, the authors have seen so much fake risk management that they close the book with a test you can use to determine whether your company is really managing risk, not just talking about it. The test is about a page long, checking for 9 key aspects of risk management. Unfortunately, most companies would score poorly on this test.

The book's title comes from a song in the Dr Seuss Cat in the Hat Songbook (Random House, 1967). Uncle Walter (or Uncle Terwilliger in some versions) finds that some risk is essential to his life: 

He goes wa-wa-wa-wa, wa-waltzing with bears, 

Raggy bears, shaggy bears, baggy bears too.

There's nothing on earth Uncle Walter won't do, 

So he can go waltzing, wa-wa-wa-waltzing, 

So he can go waltzing, waltzing with bears!

De Marco and Lister come to a similar conclusion. If a project has no risk, it's not worth doing. Companies that stick to safe projects often go out of business or have a lot of catching up to do. The authors cite the case of Merrill-Lynch in the area of online stock trading. Pioneers like E*Trade and early adopters like Fidelity and Schwab, grew dramatically in the 1990s. Merrill Lynch avoided the risks of developing an online trading facility, but struggled to stay even.

All worthy projects entail risk. The key is to manage the risk. The authors cite the case of the Denver International Airport, in which the City of Denver, apparently for political reasons, ignored and made no attempt to mitigate the risks that ultimately cost them a half billion dollars. This case is dramatic and public, but many cases like it occur every year in the more private settings of business projects.  Many companies climb the capability maturity model (CMM) ladder, and they see real benefits from doing so. Nonetheless, companies at high CMM levels often design processes that look good on paper but make no real effort to estimate the effects of risk or the expected value of completing each component of the project.  

DeMarco and Lister outline the risk part of their program this way:

1. Construct and maintain a census of project risks. Explicitly escalate to the next level any risks you don't plan to, or can't, manage.
   
2. Create an ongoing risk discovery process and develop a corporate culture that does not punish discussion of risks.
   
3. Estimate the probability that each risk will occur and the cost you will incur if it does.
   
4. Use simple math or a tool (the authors provide a free tool on their website) to create diagrams that show the uncertainty in project estimates.
   
5. Set goals optimistically, but estimate outcomes realistically, using the uncertainty diagrams.
   
6. Include mitigation actions (to be performed unconditionally) for each risk. Include these in the project's work breakdown structure.
   
7. Define a transition indicator for each risk, and define a contingency plan to go into effect if the indicator appears. Include the contingent actions in the project's work breakdown structure. 
   

There's more to it, of course, but you'll have to read the book.

The other side of the risk coin is value. The authors have no sympathy for companys that skimp on estimating value. They ridicule justifications like "we've got to have it to survive."  Their rule is to estimate value with the same precision you use to estimate cost. This should lead to uncertainty diagrams similar to those for risk. Alternatively, if the best value estimate is "we've got to have it," then an appropriate cost estimate should be "it's going to be expensive."

The authors invest a good deal of energy into fighting with general practice. Statements like "risk management is project management for adults" are meant to needle people into changing the status quo. The following statement attacks a few sacred cows:

People who don't have the requisite talent [to be a good manager] fall back on a host of mechanical approaches, such as Management by Objectives, Parkinsonian Scheduling, and "a culture of fear" to scare their subordinates into performing. . . .  These practices are incompatible with any risk management scheme.

One of the biggest parts of risk management is mitigation. This is work that you do unconditionally to lay the groundwork for contingency plans that may or may not become necessary. For the Denver International Airport, for example, this might have meant building tunnels tall enough so that humans could drive carts through them if the contractor for the automated baggage handling software did not finish on time.

Mitigation is an expense that translates into waste if the contingency plan is not necessary. The authors suggest a mitigation strategy that reduces potential waste: incremental implementation. Their plan for incremental implementation requires you to identify which parts of the project deliver the greatest value to customers and which can eliminate potential risks before mitigation actions are necessary. These are the parts you implement first. This approach provides many benefits, including pushing low valued "pet projects" to the end of the schedule, where they can often be eliminated harmlessly.

One of my favorite parts of the book -- though I doubt that it will influence many readers -- is the story of William Kingdon Clifford, who in 1876 scandalized London's Metaphysical Society with his paper, The Ethics of Belief. The authors kindly include the entire text of this paper in an appendix. Clifford held that it is unethical to hold and act upon beliefs that you have no real basis for. The authors take off from Clifford's work to define risk management as the business of believing only what you have a right to believe. 

There is a great deal of useful advice in this little book. The authors also provide practical techniques for implementing their ideas. If you have anything to do with software, you really need the information in this book.

Lean Software Development -- An Agile Toolkit by Mary & Tom Poppendieck (Addison-Wesley, 2003, Boston MA, 232pp, ISBN 0-321-15078-3, www.awprofessional.com, $39.99)

Agile software development is an umbrella term for methodologies like extreme programming (Micro Review Nov/Dec, 1999). The Manifesto for Agile Software Development (http://agilemanifesto.org/) states:

We are uncovering better ways of developing software by doing it and helping others do it. 

Through this work we have come to value: 

• Individuals and interactions over processes and tools 
  
• Working software over comprehensive documentation 
  
• Customer collaboration over contract negotiation 
  
• Responding to change over following a plan 
  

That is, while there is value in the items on the right, we value the items on the left more.

Lean manufacturing refers to the kinds of techniques pioneered by Toyota and others, as described in The Machine That Changed the World by Womack and Jones (Harper Collins, 1991). This approach regards every unnecessary element as waste. An unnecessary element can be acquiring inventory before you need to use it, deferring to management on a decision that the workers can make for themselves, or any of a wide array of similar inefficiencies. In this book the authors have pulled these lines together into what they call a set of thinking tools for bringing agile practices into your unique environment.

Like the authors of Waltzing With Bears, these authors are fighting the status quo. For example, they claim that the Project Management Institute (PMI) certification programs teach project managers to use wasteful formalistic substitutes for learning and innovation, the real keys to the success of development projects.

The authors state the following lean principles:

• Eliminate waste -- anything that does not add to the value the product brings to customers. But don't throw away all documentation.
  
• Amplify learning -- recognize that development is not manufacturing. Design, implement, get feedback, and repeat. But don't repeat indefinitely.
  
• Decide as late as possible -- keep gathering information to support your decision for as long as you can get away with (but no later -- don't procrastinate). This requires you to structure your project in a way that supports rapid change.
  
• Deliver as fast as possible -- use short cycles that give customers what they need when they need it and give you the feedback you need to refine your design. Implementation speed allows you to defer design decisions until you know enough to make them intelligently. But don't rush so much that you do sloppy work.
  
• Empower the team -- rely on the team to make decisions on the spot without referring them to a higher authority. But if you're the leader, continue to lead.
  
• Build integrity in -- provide highly usable software that gives customers exactly what they need now. Provide the infrastructure to support graceful evolution. But don't rely on a big up front design process.
  
• See the whole -- don't allow specialists to overbalance the design by focusing inordinately on their own specialties. But pay attention to details.

The book elaborates these principles into a set of 22 tools -- not a cookbook, but a schema for designing recipes. For example, the principle of building integrity in gives rise to tools called Perceived Integrity, Conceptual Integrity, Refactoring, and Testing. The authors explain the tools in the context of fascinating real world examples.

A complete commitment to agile development may not be ideal for your organization, but you might find the information in this book useful and relevant anyway. The authors bring a lot of practical experience to it, so it's worth reading, no matter what development process you follow.