Slashdot Mirror

BrianFagioli quotes a report from BetaNews: Want to know something shocking? Like, literally shocking? Barnes and Noble is recalling 147,000 faulty NOOK Tablet 7 power adapters due to shock risk. In other words, owners of this tablet could face an electricity related injury when charging it. If you own this tablet, it is important that you stop using the charger immediately. While there is no guarantee that you will be injured, it is not worth the risk. Barnes and Noble will replace the power adapter at no charge. To make up for the inconvenience, the company will also give you a free gift. "Consumers should immediately stop using the recalled power adapters and register online for a free replacement adapter along with a Barnes and Noble $5 gift card. Once registered, consumers will be able to print a pre-paid UPS label to return the recalled adapters to Barnes and Noble. Consumers will receive replacement adapters in the mail. Until a replacement adapter is received, consumers are advised to charge their NOOK Tablet 7 through their computer using a USB cable," says Barnes and Noble. The book-seller also says, "This recall involves the black power adapter sold with the NOOK Tablet 7. The adapter bears markings: model number TPA-95A050100UU, manufacture date 201610. The NOOK Tablet 7 model number BNTV450 is located on the back of the NOOK. Barnes and Noble has received four reports of the power adapter breaking or pulling apart exposing the metal prongs. No injuries have been reported." If you are affected by this recall, you can visit this site and follow the instructions.

itwbennett writes: Peter Smith writes that he 'had more or less written off the Nook when Barnes & Noble farmed hardware duties out to Samsung.' But now that Amazon is aiming for the low end with its downgraded Fire tablet line, Barnes & Noble has an opportunity to 'carve out a niche on the higher end of things,' says Smith. And so it has been quietly moving in that direction. Yesterday, Venture Beat wrote about the newly (and stealthily) launched $250 Samsung Galaxy Tab E Nook. As Smith notes, 'the specs for this new tablet aren't anything special,' which might explain the stealthy launch, except that another, pricier Nook tablet apparently came out a month ago (again, according to VentureBeat), the Samsung Galaxy Tab S2 Nook.

Velcroman1 writes "Barnes & Noble may kick off a fresh price war today for digital book readers, with its new Nook news. But the real news in digital publishing is a novel approach to the e-books themselves: Free books — with advertising. The basic idea is to offer publishers another way to reach readers and to give readers the chance to try more books — books that perhaps they wouldn't normally peruse if they had to pay more for them. Initially, Wowio specialized in offering digital versions of comic books and graphic novels, usually formatted as Adobe PDFs. So it was a natural step for the company to offer graphic ads that are inserted in e-books. 'We think we're creating a broader audience for some of these titles,' Wowio's CEO Brian Altounian told me. 'I think folks are going to download more books because they're saving the costs' of having to drive to the store or pay more for them. Would ads stop you from reading?" The new color Nook goes for $249, and comes with a browser, games, Quickoffice, streaming music via Pandora, and an SDK; reader itwbennett links to an analysis of how well it stacks up as a tablet.

jacob1984 writes "A few years ago there was a question about which e-reader was the best. Since then, the market has been flooded with new additions, many of them more open than others. Have you bought one yet? If so, which one did you find best and why?"

GeekZilla sends coverage from Wired's Gadget Lab on the Nook, Barnes & Noble's first e-book reader. "Sleek, stylish and runs the Android OS. What's not to like about Barnes and Noble's new e-book reader? Despite the odd name, the Nook looks like an eBook reader that would actually be a worthwhile investment. Best feature? The ability to loan e-books you have downloaded to other Nook owners. The reader, named the 'Nook,' looks a lot like Amazon's white plastic e-book, only instead of the chiclet-keyboard there is a color multi-touch screen, to be used as both a keyboard or to browse books, cover-flow style. The machine runs Google's Android OS, will have wireless capability from an unspecified carrier, and comes in at the same $260 as the now rather old-fashioned-looking Kindle." Here is the B&N Nook site, which is still not visible on their front page and has a few non-working links. (Nook.com isn't set up yet.) Their comparison page takes dead aim at the Kindle. Among the advantages in the Nook's column: Wi-Fi, expandable memory via microSD, MP3 player, and PDF compatibility. (But remember the cautionary note B&N struck six years back when they got out of the e-book business.)

GeekZilla sends coverage from Wired's Gadget Lab on the Nook, Barnes & Noble's first e-book reader. "Sleek, stylish and runs the Android OS. What's not to like about Barnes and Noble's new e-book reader? Despite the odd name, the Nook looks like an eBook reader that would actually be a worthwhile investment. Best feature? The ability to loan e-books you have downloaded to other Nook owners. The reader, named the 'Nook,' looks a lot like Amazon's white plastic e-book, only instead of the chiclet-keyboard there is a color multi-touch screen, to be used as both a keyboard or to browse books, cover-flow style. The machine runs Google's Android OS, will have wireless capability from an unspecified carrier, and comes in at the same $260 as the now rather old-fashioned-looking Kindle." Here is the B&N Nook site, which is still not visible on their front page and has a few non-working links. (Nook.com isn't set up yet.) Their comparison page takes dead aim at the Kindle. Among the advantages in the Nook's column: Wi-Fi, expandable memory via microSD, MP3 player, and PDF compatibility. (But remember the cautionary note B&N struck six years back when they got out of the e-book business.)

Videogames may be nothing more than evening diversions to most Americans, but the industry as a whole is a multi-billion dollar heavyweight. Microsoft broke ground in the business when the Xbox launched in 2001, and came back swinging last year with the Xbox 360. The war for the seventh generation of game consoles has barely begun, and it's hard to know the score without a scorecard. We can get a good look at the odds, though, thanks to the reporting of Dean Takahashi. The author of the definitive book on the original Microsoft console, Opening the Xbox, offers the complete story of their next-gen offering in the recently published The Xbox 360 Uncloaked. A sometimes exhausting read that could have been more concisely edited, Uncloaked still highlights the human side of a complicated technical and business endeavor. Read on for my impressions of Takahashi's new look behind the curtains at Microsoft. The Xbox 360 Uncloaked: : The Real Story Behind Microsoft's Next-Generation Video Game Console author Dean Takahashi pages 404 Pages publisher Lulu Press rating 7 reviewer Zonk ISBN 0977784215 summary A veteran games reporter looks behind the scenes at the creation of a next-gen videogame console. When the original Microsoft console launched in 2001, the sequel system was already in the planning stages. Dubbed 'Xenon' as its codename, the Xbox 360 came together over the next four years in a flurry of effort from a series of dedicated teams. The Xbox 360 Uncloaked breaks that process down, takes the reader behind the scenes, and explains the entire process in layman's terms; From the lessons of the first Xbox to the launch day and beyond, the amount of information presented here is staggering.

The term staggering is meant literally. It's obvious from the tone of the book and the description of the process that the months after the original Xbox's launch were confusing and demoralizing. Many of the principle architects of Microsoft's first console left the company or moved to other projects, and the second generation of executives were hard pressed to restart the process after only a short break. Moreover, the console they'd worked so hard to see launched was only doing so-so in the marketplace. The result is a long period of soul-searching and analysis that lasted two years and covers 25 of the 53 short chapters in the book. This real life confusion and frustration translates into the book in the form of a fractured narrative.

The first 10 or 12 chapters of Uncloaked are very hard on the reader. Takahashi has deliberately used a lot of repetition to drill into the reader basic concepts, events, and characters; This is a mixed blessing. While the repetition results in basic information retention, combined with the muddled events it doesn't make for very entertaining reading. This problem is exacerbated by some lax editing. I read the book in eBook format, so I can't speak to the editing in the final print version, but at least the .pdf edition contained several unreadable sentences and nonsensical paragraphs that the editors simply missed.

I was beginning to be frustrated with the work when, like the executives on the 360 project, The Xbox 360 Uncloaked found a clear path and began driving forward. Right about the time that Robbie Bach and Co. found a way to tackle the project's scope, the writing focuses into the same cohesive voice readers of Takahashi's Mercury News column are used to. The chapters begin to fly by, with each successfully capturing a specific aspect of the 360 production process. From the famous meeting of CliffyB and Ed Fries at DICE 2003, to the exhaustive industrial design phase, all the way through the GDC and E3 events of last year, the tough choices and design decision are laid out for the reader. The final half-dozen chapters deal with the launch and the immediate aftermath.

What makes this book such an informative tome is the depth of information and the balance in the reporting. The author had a great deal of access to the principal figures involved in the creation of the console. What's refreshing, though, is how this access doesn't seem to have clouded his judgment of the events he bears witness to. In the final chapters he speculates on how Microsoft is poised within the console war, with some pointed observations on the console's launch that proves Takahashi is far from a company mouthpiece.

It's this outsider's viewpoint that ultimately makes The Xbox 360 Uncloaked a success. Takahashi looks at the creation of the Xbox with the dispassionate voice of a journalist. Hype and hyperbole surrounded the system's launch to such a degree that it was hard to see through the agendas held by the marketers, advertisers, and the fan press. This surprisingly lively business book condenses half a decade of effort into four hundred pages of mostly understandable prose. It provides insight into the players, the technology, and the corporate culture that has launched two remarkably popular game consoles in a span of six years. I definitely feel it could have been more thoroughly edited. That said, if you have any interest in the business climate at Microsoft or the process of creating a major work of consumer electronics, The Xbox 360 Uncloaked will lay out both the good and the bad of the 360's torturous journey to market.

You can purchase The Xbox 360 Uncloaked from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

The history of videogames is a subject that has been remarkably well documented. From Pong to the launch titles of the 360, games have always had historians. Now that gaming is taking its place beside movies and music as a recognized art form, new players have to be informed of the hobby's past. Smartbomb: The Quest for Art, Entertainment, and Big Bucks in the Videogame Revolution tells the tale of modern gaming's formation via the personal stories of the people who make them. It's a well-considered look at the early days and recent history of interactive entertainment. Read on for my impressions of a book with not only a sense of history, but a handle on what's fun. Smartbomb author Heather Chaplin and Aaron Ruby pages 287 publisher Algonquin Books of Chapel Hill rating reviewer Zonk ISBN 978-1-56512-346-5 summary A look at the events that formed the games industry from within. If you don't follow games, you won't recognize the name of CliffyB. Suffice it to say that Cliffy (a designer at Epic Games, makers of the Unreal series) has a reputation in the games industry. His swagger and bravado at industry events early in the decade fills the first chapter of the book, and had me sighing. While I respect the man's work, I have a low tolerance for that kind of machismo. Cliffy has changed since then, though, and despite the image he portrayed back then the authors of the book make it clear that the swagger was all an act. As they describe the man's dissatisfaction with his situation, and a humanizing moment where he walks from a dance floor seeking solitude, it was clear that Smartbomb was not going take a superficial look at the games industry or its people.

Smartbomb uses the individuals who make and play the games we love as lenses to focus on distinct segments of the videogame industry. Each chapter is a mini-novel, with characters and reflections that explore the roots of gaming as an art form, as a medium, and as a culture. The story of Nolan Bushnell and the early days of Atari are a lead-in to the formative years of the home gaming scene. Through the eyes of Shigeru Miyamoto we see the ascendency and decline of Nintendo in the Western market. Angel Munoz's CPL tournament allows us access to the world of FPS titles, and lets us lament the loss of Looking Glass studios all over again. Seamus Blackley attends the launch of the original Xbox, and we tag along to reflect on Microsoft's bid for the living room.

Though the outlines of much of this may be familiar to anyone who's been a gamer for a while, the immediacy of the book's language places you in the flow of history as it unfolds. They don't just tell you about the Xbox launch, they put you in the moment. You're standing there as Gates plays a round with The Rock, and are a fly on the wall as Blackley proposes to his girlfriend. Though the tone feels somewhat unnecessary at times (we don't have to 'be there' to see Will Wright's buddy making a fool of himself at a GDC), it breathes life into what could have been very dry material.

The story of Smartbomb, the oral history of the gamers, is not dry in the slightest because the authors make it a human tale. During the course of the book there are plenty of games to talk about, but the authors chose to focus their attention on the people behind the games. It pulls our attention as readers away from the subject matter and forces us to consider gaming history in a more holistic way. For example, the launch of Star Wars Galaxies, discussed in a chapter on Raph Koster and virtual worlds. The game's launch was a harsh time for everyone involved. It lead to harsher times and marked the start of a game that has always been troubled. The authors force us to consider the human toll that must have taken, revealing that the live team was in crunch mode for almost three years after the game's launch. Several Christmases away from your loved ones is a high cost to pay for fun gameplay. In addition to humanizing raw statistics, the tone of the book forces the reader to see these people as no more or less than human. Will Wright's genius is well known, but he's an intimidating person to talk to. The launch of the Xbox saw a lot of friendships broken up, and thousand dollar purses at the CPL are won by teens and young adults who spend far too much time in front of a PC screen.

The chapter in the book most likely to deal with new ground for the reader shares its title with the entire work. Though it doesn't use that term, the 'Smartbomb' chapter touches on serious games. The most serious of games, actually, the ones the military is using to train the next generation of soldiers. Where the other chapters talk about the creation of an industry and the advancement of a hobby, 'Smartbomb' introduces the reader to games like America's Army and Full Spectrum Warrior. The human face of military gaming are the men and women who developed the titles, and are even now adapting lessons learned from their play to training programs for U.S. soldiery. Humanized in the same way as the more jocular portions of the book, the look at gaming and the military is probably going to be the most informative for gamers already familiar with the rest of the text's characters.

The book accomplishes some admirable goals in relating the history of the hobby, the industry, and the people who have made both possible. Despite that, there are some elements I felt could have been better. Average players are included in some portions of the tale, and the device would have been more effective if it had been used throughout the book. Impressions from a Sims player would have been a poignant offset to the cloud castles of Will Wright's thought processes. While the book does an admirable job of grounding some icons it doesn't do so evenly; Some industry personalities are brought to earth harder than others. The book ends on a postscript during 2005's GDC, and the few sentences mentioning the designers' views on the modern industry were not satisfying. Revealing the founders of modern videogaming as human could have been followed by more exploration of that humanity, an opportunity missed.

Alongside titles like Masters of Doom and Dungeons and Dreamers, Smartbomb is a stab at capturing some legitimacy for the community by creating well-informed members. It uses a casual tone to relate the tales of videogaming past, and places readers in the middle of the moment. This first-person perspective of history is certain to appeal to readers who might otherwise not be interested in the formation of an industry. As an extension of gaming's oral history, the book accomplishes its objective well. It's both informative and entertaining, a title you can feel comfortable giving to a non-gamer without pause. For long-time gamers, familiarity with the book's subject matter may detract from your enjoyment. The only truly new story that 'Smartbomb' tells is that of the military's involvement with gaming. Many of the most interesting aspects of the book are anecdotes gamers have been telling each other for years. That said, those who enjoy gaming history will enjoy Smartbomb. It treats the subject matter with respect and the icons of the gaming world as people. It is a well-crafted look at an immature medium, and will hopefully open up younger readers to the events that prompted the news of today.

You can purchase Smartbomb: The Quest for Art, Entertainment, and Big Bucks in the Videogame Revolution from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Ben Rothke writes "Thousands of computer security books have been published that deal with every conceivable security issue and technology. But Insider Threat is one of the first to deal with one of the most significant threats to an organizations, namely that of the trusted insider. The problem is that within information technology, many users have far too much access and trust than they should truly have." Read the rest of Ben's review. Insider Threat author Eric Cole and Sandra Ring pages 397 publisher Syngress rating 9 reviewer Ben Rothke ISBN 1597490482 summary Excellent overview of the insider threat to networks and information systems

The retail and gambling sectors have long understood the danger of the insider threat and have built their security frameworks to protect against both the insider and the outsider. Shoplifters are a huge bane to the retail industry, exceeded only by thefts from internal employees behind the registers. The cameras and guards in casinos are looking at both those in front of and behind the gambling tables. Casinos understand quite well that when an employee is spending 40 hours a week at their location dealing with hundreds of thousands of dollars; over time, they will learn where the vulnerabilities and weaknesses are. For a minority of these insiders, they will commit fraud, which is invariably much worse than any activity an outsider could alone carry out.

Insider Threat is mainly a book of real-life events that detail how the insider threat is a problem that affects every organization in every industry. In story after story, the book details how trusted employees will find weaknesses in systems in order to carry out financial or political attacks against their employers. It is the responsibility to the organization to ensure that their infrastructure is designed to detect these insiders and their systems resilient enough to defend against them. This is clearly not a trivial task.

The authors note that the crux of the problem is that many organizations tend to think that once they hire an employee or contractor, that the person is now part of a trusted group of dedicated and loyal employees. Given that many organizations don't perform background checks on their prospective employees, they are placing a significant level of trust in people they barely know. While the vast majority of employees can be trusted and are honest, the danger of the insider threat is that it is the proverbial bad apple that can take down the entire tree. The book details numerous stories of how a single bad employee has caused a company to go out of business.

Part of the problem with the insider threat is that since companies are oblivious to it, they do not have a framework in place to determine when it is happening, and to deal with it when it occurs. With that, when the insider attack does occur, which it invariably will, companies have to scramble to recover. Many times, they are simply unable to recover, as the book details in the cases of Omega Engineering and Barings Bank.

The premise of Insider Threat is that companies that don't have a proactive plan to deal with insider threats will ultimately be a victim of insider threats. The 10 chapters in the book expand on this and provide analysis to each scenario described.

Chapter 1 defines what exactly insider threats are and provides a number of ways to prevent insider threats. The authors note that there is no silver bullet solution or single thing that can be done to prevent and insider threat. The only way to do this is via a comprehensive program that must be developed within the framework of the information security group. Fortunately, all of these things are part of a basic information security program including fundamental topics like security awareness, separation and rotation of duties, least privilege to systems, logging and auditing, and more.

The irony of all of the solutions suggested in chapter one is that not a single one of them is rocket science. All of them are security 101 and don't require any sort of expensive software or hardware. Part of this bitter irony is that companies are oblivious to these insider threats and will spend huge amounts of money to protect against the proverbial evil hacker, being oblivious to the nefarious accounts receivable clerk in the back office that is draining the coffers.

One example the book provides is that many companies feel they are safe because they encrypt data. An excellent idea detailed in chapter two is to set up a sniffer and examine the traffic on the internal network to ensure that the data is indeed encrypted. The reliance on encryption will not work if it is not setup or configured correctly. The only way to know with certainty is to test it and see how it is transmitted over the wire. Many companies will be surprised that data that should be unreadable is being transmitted in the clear.

Some of the suggestions that authors propose will likely ruffle some feathers. Ideas such as restricting Internet, email, IM and web access to a limited number of users may sound absurd to some. But unless there is a compelling business need for a user to have these technologies, they should be prohibited. Not only will the insider threat threshold be lowered, productivity will likely increase also.

The author's also suggest prohibiting iPods or similar devices in a corporate environment. The same device that can store gigabytes of music can also be used to illicitly transfer gigabytes of corporate data.

Insider Threat provides verifiable stories from every industry and sector, be it commercial or government. The challenge of dealing with the insider threat is that it requires most organizations to completely rethink the way they relate to security. It is a challenge that many organizations would prefer to remain obvious to, given the uncomfortable nature of the insider threat. But given that the threats are only getting worse, ignoring them is inviting peril.

The only lacking of the book is that even though it provides a number of countermeasures and suggestions, they are someone scattered and written in an unstructured way. It is hoped that the authors will write a follow-up book that details a thorough methodology and framework for dealing with the insider threat.

Overall, Insider Threat is an important work that should be required reading for every information security professional and technology manager. The issue of the insider threat is real and only getter worse. Those that choose to ignore it are only inviting disaster. Those companies that will put office supplies and coffee under double-lock and key, while doing nothing to contain the insider threat are simply misguided and putting their organization at risk.

Insider Threat is a wake-up call that should revive anyone who doubts the insider threat.

Ben Rothke, CISSP is a New York City based security consultant and the author of Computer Security 20 Things Every Employee Should Know (McGraw-Hill 2006) and can be reached at ben@rothke.com"

You can purchase Insider Threat from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

FrazzledDad writes "Andrew Troelsen's Pro C# 2005 and the .NET 2.0 Platform, 3rd Ed. gives a great breadth and depth of coverage to C# and the features of Microsoft's .NET 2.0 Framework. He does a fine job covering fundamentals of C# and .NET in general and then dives into terrific detail on a number of important topics." Read the rest of Jim's review. Pro C# 2005 and the .NET 2.0 Platform, Third Edition author Andrew Troelsen pages 1032 publisher Apress rating 8/10 reviewer Jim Holmes ISBN 1590594193 summary Great coverage and detail on many C# topics, but long

Troelsen claims that the book is targeted at "experienced software professionals and/or graduate students of computer sciences," and that he won't spend "three chapters on iteration or decision constructs," but he spends enough time covering basics that the book will be beneficial to developers of any skill level.

First off, the book is longer than it needs to be. Part of this is the amount of text Troelsen spends covering fundamentals, despite his claims of the book's targeted audience. Experienced developers will skip right over the sections on object-oriented programming basics and C# language fundamentals. Still, this extra material didn't particularly bother me and it's very useful to newer developers, or those needing a refresher on basics.

Troelsen's example code also has more cruft than necessary, which tends to drag out examples a bit too much. The auto-based example he carries through the book is a nice practical example, but do I really care about methods turning the radio on and off while not lending any weight to the concept?

I was also surprised to find missing any discussion of COM interoperability. While COM Interop isn't a sexy, futuristic topic, I'd think there would be great value in covering it - helping some developers understand how to better deal with migrating or wrapping up legacy applications.

Lastly, despite the book's title emphasizing C#, there are 130 or so pages on ASP.NET and XML web services. Sure, these are part of the .NET Framework, but it seems a diversion from focusing on C#.

Frankly, the bad items I list above are all nits to me in what I consider a very worthwhile book. The book's loaded with plenty of good material, starting out with a solid overview on developing .NET applications outside Microsoft's Visual Studio.

Troelsen nicely covers using the freely available .NET Framework SDK to build applications. He also mentions Textpad and has a handful of pages dedicated to SharpDevelop, the open source C# development environment. He also gives a short nod to the freely (for now!) downloadable Visual C# 2005 Express before moving into an overview of the upscale versions of Visual Studio.

Troelsen nicely lays out critical concepts in his book. His work is the first place I've found clear explanations of why one should occasionally drill into .NET's Common Intermediate Language (CIL, sometimes referred to as "IL"). Other articles and books I've read haven't really gone past the level of "gee, it's neat!", but Troelsen lays out good examples of when it can be useful - such as inspecting IL and finding out how to directly call operator overloads ("+=", for example) in languages which might not support this feature.

I also found Troelsen's discussion of remoting and serialization very clear and useful. Furthermore, he does a great job with delegates and events, starting out with manually working with event handlers. This helps the reader understand the fundamental workings of handler assignments and multicasting rather than just directly jumping to event handling assignment via the += operator.

Even better than Troelsen's conceptual coverage is the level of detail he brings to all the topics he writes on. I already mentioned his coverage of event/delegate multicasting as one example. Other examples would be his extensive coverage of reflection, late binding and threading, among other topics.

He dedicates one chapter to the guts of .NET assemblies, running the gamut from why assemblies exist, through the format of assembly headers, to how shared assemblies work. There's good discussion in this chapter on the what/why/how of the Global Assembly Cache and how to deal with publishing assemblies with policy interraction.

There's plenty of other goodness in this book. Generics get great coverage, as does ADO.NET and multi-threading. There's also a chapter dedicated to GDI+ programming for you graphics geeks.

It's nice that Troelsen carries one example through much of the book, building concepts on the same framework of his automobile classes. Source for his examples is available from Apress's website, and Apress also has a searchable e-book available. The e-book's available for free for short time if you purchase the hardcopy.

Troelsen's writing style is also easy to deal with. He's got a good writing voice which makes potentially dry stuff interesting.

It may be overly long for some folks, but this book is a worthwhile investment for those looking for clear, detailed explanations of C#. The length really doesn't detract from the book's overall value, and I'm happy to have it on my bookshelf. (I even pull it off and use it.)"

You can purchase Pro C# 2005 and the .NET 2.0 Platform, Third Edition from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

norburym writes "Peter Morville is an information architect, an advocate of expanding the boundaries of librarianship in an Internet age and the voice of ambient findability. In this new book from O'Reilly, Morville expands on a theme he's been discussing for several years: we live in an age where computers and the Internet are changing how we access information. Digital networks are available everywhere. As users, we have computers, PDAs, GPS units, smartphones, software and other network technologies that enable constant and mobile connectivity. As Morville writes, ambient findability is "a realm in which we can find anyone or anything from anywhere at anytime" and his book is a thought provoking chronicle of the advent of that goal." Read the rest of Mary's review. Ambient Findability author Peter Morville pages 204 publisher O'Reilly Media rating 9 reviewer Mary Norbury-Glaser ISBN 0596007655 summary Information retrieval in an age of ubiquitous computing.

Ambient Findability is divided into seven sections that track the journey from simply defining what the author means by findability through a history of man's search for location awareness in both the physical environment and in the cyber world; how we interact with information through documents, language, and systems of retrieval; intertwingularity and findable objects; the balance between push (advertising) and pull (information retrieval); being a Web designer and a user advocate; metadata and physical data in the context of findability; and the ability to make informed decisions based on open source and emerging technology.

A core definition offered by the author in Chapter 1 is for findability: "the quality of being locatable or navigable; the degree to which a particular object is easy to discover or locate; the degree to which a system or environment supports navigation and retrieval." Morville discusses how well various websites perform in providing information desired by the user and how successful sites cater to mass customization. Businesses and non-profits that aim to reduce search time and improve findability of their site contents will gain marketplace advantage.

Chapter 2 is an interesting and informative introduction to the history of wayfinding through lessons learned from various animal species (exocentric and egocentric navigation, echolocation, etc.) to how humans have adapted landmarks or created tools to aid in navigation and exploration (lighthouses, compasses, sextants, maps, etc.) and further how architects and urban planners can effectively design built environments. The logical extension of this discussion is how the wayfinding techniques developed in the physical world have translated to the digital realm. In this discussion, we see how we have translated our spatial metaphors to the web.

This leads directly to the next chapter, on how people interact with information. Morville tackles the difficult task of defining information and considers the concept of relevance in relationship to the information we seek to retrieve from the Internet and how the inherent ambiguity of language negatively impacts any system of information retrieval. To top this off, the author reminds us that users themselves introduce added complexity and complication to how people seek information. He cites several research studies and literature on the subject and suggests that there is value in integrating both push and pull in how we interact with information systems.

Chapter 4 deals with the topic of intertwingularity (a combination of "intertwined" and "mingled") or the idea that things are connected together in a complex and nonlinear way. In terms of the Internet and ubiquitous computing, this translates into our ability to connect to disparate bits of data not only from computers but also from mobile devices and other ambient devices (GPS, EZPass, pagers, RFIDs) that are truly pervasive throughout society. Morville takes us through part two of wayfinding with descriptions of GPS technology, interactive mapping and photographic confluence sites, tracking using GPS and cellular communication, RFID, webcams, and of course the convergence of technology as wearable computing (sunglasses that can be used with cell phones and MP3 devices, Bluetooth enabled garments, cameras embedded in glasses, etc.) becomes more common and affordable.

Morville then leads us neatly back to the idea of push and pull. In chapter 5, he discusses the necessary flow toward balance and uses the example of Google, which successfully intertwingles unobtrusive targeted ads with search results. Design and marketing, as the author notes, are not enemies. Yet finding the balance is tricky and not a simple task. Morville describes his "user experience honeycomb" model which combines the key issues that designers should consider when creating a website that optimizes findability and therefore enhances user experience: useful, usable, desirable, findable, accessible, credible, and valuable. He concludes the chapter with hacks that improve web findability: adopting search engine optimization techniques (avoid drop down menus, image maps, frames, etc.; use RSS feeds with backlinks; embrace web standards; determine and include keywords and phrases in visible body text, links, headers, tags, etc.), and personalization (examples include Yahoo! using individual profiles to customize sports scores and stock information, the Weather Channel using zip codes for local weather, and Google Alerts letting users track keywords in news and web sites).

In chapter 6, "The Sociosemantic Web," Morville outlines the controversy surrounding an article, "The Semantic Web," that appeared in May 2001 in the Scientific American. The authors of the article propose an ambitious "road map for future Web design" that subsequently fueled a debate between W3C Semantic Web members and social software supporters. The debate leads to a discussion about how well metadata can be normalized in an environment such as the Web. Morville uses this debate as an introduction to a history and structural description of metadata. He describes the formulation of taxonomies and the use of controlled vocabularies to enable findability. Of course, web sites are not simply hierarchical; they are complexly grouped which brings us to the idea of folksonomies where users tag objects with one or more keywords that become shared. Folksonomies are obviously not great for findability since they fail at semantic relationships and hierarchy. However, all forms of structure (folksonomies, ontologies, and taxonomies) can co-exist on the Web to describe metadata and the differences between data and metadata are becoming less distinct. Amazon is a perfect example of this: traditional publication and topic details and concordance are documented along with customer reviews and rankings. Amazon also has the option to "search inside this book" which makes the pages and even the text itself become metadata.

The final chapter of the book delves into how we are ultimately capable of making informed decisions through the power of the Internet: the sheer volume and variety of sources available to us and the ease of access enable us to take charge of decisions we would normally trust to those professionals outside of our narrow realm of expertise. We decide which information to believe in. Morville considers information literacy and digital librarianship and proffers the idea that libraries and the Internet have common principles of maintaining free expression, privacy, free and equal access, and intellectual freedom.

Tim O'Reilly is well known for expanding the boundaries of technology in print and through conferences like the Emerging Technology Conference, the Web 2.0 Conference, and the Open Source Convention held in both the US and in Europe. His agenda has never been to fill convention halls with attendees who fit a lowest common denominator; his aim has been to bring together people who not only think smart but who also have the ability to think outside the normal boundaries of their particular field of interest (Robert J. Lang, Freeman Dyson, James Gosling, among others) and who therefore inspire innovation. With the publication of Ambient Findability, O'Reilly Media continues this tradition of giving readers an opportunity to experience the visionary writing of people like Peter Morville.

Read Ambient Findability if: you are interested in expanding your business or nonprofit through its presence on the Internet; you are a librarian and want to grow into the nontraditional environment of the Web; you are a Web designer and want to optimize the findability of your sites on the Internet; you are a user and want to enhance your searching experience. Read this book if you are a teacher, a student, a writer, a parent...in short, if you use a computer or a handheld or a GPS or a smartphone or any type of technology that connects you to the world, then you should read this book. Peter Morville's Ambient Findability will amaze and delight you. It will give you new insight into how ubiquitous computing is affecting how we find and use information and how we, as users, can and will shape the future of how data is stored and retrieved.

Mary Norbury-Glaser is IT Director at the Barbara Davis Center, an affiliate center at the University of Colorado Health Sciences Center in Denver."

You can purchase Ambient Findability from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

James Alguire writes "Anyone who's tinkered with LEGOs, Lincoln Logs, or an Erector Set knows the thrill of turning ideas into something tangible. Even if all you've ever done is assemble IKEA furniture, you've felt the satisfaction of turning a collection of parts into a functional object with your own two hands. Makers: All Kinds of People Making Amazing Things In Garages, Basements, and Backyards by Bob Parks, and published by O'Reilly, celebrates the basic human desire to create, to nail together two things that have never been nailed together before and see what it does. While I have worked in construction, built computers from scratch and done my share of soldering, I still felt a sense of wonder after reading about the 76 projects outlined in this book." Read the rest of James's review. Makers: All Kinds of People Making Amazing Things In Their Backyard, Basement or Garage author Bob Parks pages 184 publisher O'Reilly rating 8/10 reviewer James Alguire ISBN 0-596-10188-0 summary

Makers profiles 91 people from around the planet, from high school students to dedicated scientists who have cobbled together a remarkable array of home built devices. Some are answers specific needs, like Zach Radding's automated parts dispenser powered by a personal computer; or to further scientific discovery, like Dan Bowen and Mike Coffey's low cost high-altitude weather balloon and tracking package. Some, like Bathsheba Grossman's sculptures, printed from digital CAD files to metal, and Owen White's computer controlled laser cutter, bridge art and science. Others, including Tom Chudleigh's spherical wooden treehouses, or Matty Sallin's alarm clock, that wakes the sleeper by cooking bacon, merely fulfill some puckish desire. All the projects reveal the ingenuity, skill, foolishness, risk and passion humans are capable of in pursuit of their dreams.

Each profile identifies the "Maker", their profession, geographic location, the cost of the project being profiled, the amount of time the project took to complete and a web site where more information about the project can be found, followed by a description of the project, the process of creation, the technology used, the reasons for doing it, including pithy comments from the makers themselves. Bob Parks' writing is fresh and crisp and each vignette provides insight into how to think a little sideways about technology.

The concept for Makers grew out of the success of O'reilly's quarterly do-it-yourself (DIY) magazine, Make: Technology on Your Time. The publication provides recipes for modding, tweaking or reworking personal technology, and profiles of DIY people and their clever contraptions.

The book provides an interesting mix of cool gadgets to consider; from Douglas Repetto's motorized table that emulates the movements of a baby horse, and Kelly Dobson's voice activated blenders, that respond to their own language, to several "don't try this at home" devices like Richard Flanagan's jet engine powered go-kart (up to 60 miles per hour), Matthew Stiger's washtub Tesla coil (it shoots 7-foot sparks), or Richard Hull's homemade nuclear fusor (that's right your neighbor could be experimenting with nuclear fusion in his garage). I was surprised by the number of projects that were constructed from recycled components, many scrounged from devices on hand, purchased cheaply on eBay, or dug out of dumpsters.

Two of my favorites from the book are a machine that solves Rubik's Cubes (in about 10-minutes) built entirely from LEGOs by J.P. Brown, and probably the most poignant profile in the book, Sathya Jeganathan, a physician in India, improvised baby warmers, built using standard light bulbs for about $100 replacing expensive modern warmers costing $4000 that are difficult to maintain. Using the improvised warmers has cut infant mortality in Sathya's hospital by 50%.

Makers: All Kinds of People Making Amazing Things In Garages, Basements, and Backyards is a compact hardcover book that would be at home on any geek's coffee table. The profiles are brief but thought provoking, and the whole effect provides a new view into the serious and whimsical aspects of technology. After reading this book you will definitely look at old appliances and electronics with a different eye. Personally, I would like to have seen more step-by-step photos for many of the projects, but the included images and diagrams are high quality and give you a good impression of the gadgets. I also had problems with the text in the maker summaries, at the top of each profile. It was printed in a smaller typeface than may be comfortable for some and the light blue ink was difficult to read in some lighting situations. One of the best features is the URL listed in each profile where the reader can get even more information about the projects. If you like to tinker with technology then definitely check this book out. and if you can't get enough go to the Make Magazine's online site for even more do-it-yourself techno-hacking.

You can purchase Makers: All Kinds of People Making Amazing Things In Their Backyard, Basement or Garage from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Ben Rothke writes "Noted security veteran Bruce Schneier has observed that for those organizations that have incorrectly deployed cryptography, it is akin to putting a big flagpole in front of your facility and hoping that it will stop any attackers from breaking in. Of course, any attacker with intelligence will simply go around the flagpole rather than running into it." Read the rest of Ben's review. Securing IM and P2P Applications for the Enterprise author Paul Piccard pages 454 publisher Syngress rating 9 reviewer Ben Rothke ISBN 1597490172 summary How to get a handle on the increasing number of IM, P2P, and IRC applications that are found on the corporate networks

Similarly, many organizations have deployed myriad security hardware and software products in their infrastructure. But when it comes to instant messaging and peer to peer applications, these applications often execute below the radar of many security products. This is due to the fact that the security infrastructure in many organizations was not architected to deal with such applications. These applications often have so much functionality that it obviates much of the security afforded by the security hardware and software products.

Using file transfer as an example, many organizations have policies and controls in place to stop the use of protocols such as ftp and tftp. This is fine, but that will only work for the ftp protocol. File transfer can still be carried out by most instant messaging clients, and that can pose serious security risks.

With that, Securing IM and P2P Applications for the Enterprise provides an excellent overview on how to handle, manage and secure IM, P2P, and IRC applications. This book is written for security and system administrators that need specific details on how to control and secure IM, P2P and IRC applications in their organization.

The need to get a handle on IM and P2P is crucial given that IM has turned into a global communications medium with most organizations today reported that they allow it for business usage. Many marketing and technical support calls are now handled via IM and this translates in to well over 250 million IM users worldwide. P2P is great for downloading music and movies, but that that poses serious security and legal liability risks when done on most corporate networks.

But with all the benefits that IM provides, it introduces many security and privacy risks. IM viruses, identity theft issues, phishing, spyware and SPIM (SPAM over IM) are just a few of the many risks. These risks can turn into intellectual property losses and legal liability issues especially when they are combined with targeted attacks on corporate IM users. Companies that don't have an effective way in which to deal with IM and P2P are in serious danger as most IM and P2P threats fly under the radar of many traditional security solutions.

The book has a fairly straightforward approach. Chapter 1 provides an introduction to IM and the most common security issues that IM brings into an organization. The bulk of the remainder of the book details various different IM applications in Part 1 (AIM, Yahoo, MSN, ICQ, Google, Skype), P2P applications in Part 2 (Gnutella, eDonkey/eMule, BitTorrent, FastTrack) and IRC networks and applications in Part 3.

Each chapter details the specific architecture of each application, its protocols, security issues, and solutions in which to secure the application. System administrators can use many of the checklists to quickly perform the initial steps necessary to secure their organization from unauthorized IM, P2P, and IRC applications.

Each chapter also provides significant details about the internals on how each application operates. In addition, various 3rd-party tools that can be used to secure and limit the various applications are listed.

Many companies are finding that a significant amount of their bandwidth is being used by P2P applications and Part 2 describes how to secure networks from the use of P2P applications. This is not always an easy thing to carry out given that many P2P applications, such as Gnutella are designed to easily bypass many of the security control mechanisms placed against it. Administrators will find that in this case, simply blocking Gnutella ports will not block all Gnutella traffic and the application still will be able to run. What is required in this case is the use of a firewall that supports deep packet inspection. Chapter 9 helpfully lists the commands to use when using iptables to block Gnutella traffic.

Chapter 12 provides an interesting look at FastTrack, which is the P2P protocol and network used by clients such as Grokster, Morpheus and other file sharing programs. The chapter also uses Ethereal to detail the internals of FastTrack.

Part 3 deals with IRC and is the sparsest part of the book. This is due to the fact the P2P and IM are much more heavily used on enterprise networks, which this book is geared to.

The only negatives about the book are its price, and some of its formatting. At $49.95, it is on the higher-end of computer security books, with the majority of such titles being in the $25.909 - $39.99 range. The formatting uses a font size that is somewhat larger than other book. This seemingly serves to achieve a high page count.

In addition, the book often references tables of secondary information that spans a few pages (for examples see pages 72-80, 115-120 and more). Such information would be better served in a multiple-column table in a smaller font. Printing the information in such a manner can cut down on the page total, and save a few trees at the same time.

Besides those two minor issues, Securing IM and P2P Applications for the Enterprise is a most helpful guide. Security and system administrators can use the book to get a handle on the increasing number of IM, P2P, and IRC applications that are found on the corporate networks they support.

Ben Rothke, CISSP is a New York City based senior security consultant with ThruPoint, Inc. and the author of Computer Security 20 Things Every Employee Should Know (McGraw-Hill 2006) and can be reached at ben@rothke.com"

You can purchase Securing IM and P2P Applications for the Enterprise from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

norburym writes "The Bruce Perens Open Source Series of books published by Prentice Hall PTR is a strong collection of nearly 20 volumes focusing on Linux and open source technology. Edited by Linux guru and former Debian GNU/Linux Project Leader, Bruce Perens, the books are aimed toward developers, sysadmins and power users. Several months following the release of a new print volume, a free electronic version is made available on Prentice Hall PTR's web site. The series includes some excellent editions including Official Samba-3 HOWTO and Reference Guide (2nd ed.), Linux Quick Fix Notebook and PHP 5 Power Programming. The newest book by Mark Wilding and Dan Behman, Self-Service Linux: Determining Problems and Finding Solutions, is another well-written and worthy companion to this series." Read the rest of Mary's review. Self-Service Linux: Determining Problems and Finding Solutions author Mark Wilding and Dan Behman pages 456 publisher Prentice Hall, PTR rating 8 reviewer Mary Norbury-Glaser ISBN 013147751X summary Linux Troubleshooting

This is not a basic Linux HOW TO book: authors Wilding and Behman take the reader to a level past the introductory Linux OS installation instructions and KDE/GNOME window dressing changes. In all real life scenarios and at some critical point, a Linux user or admin will need to troubleshoot some aspect of the system they use at home or the systems they manage on the job. This book is for that power user, systems administrator or developer who will, out of base necessity, require a proper bag of tools and practical guidance in establishing an effective set of skills for troubleshooting one or more Linux systems.

A quick scan of the table of contents gives a very abbreviated summary of the book and actually belies the depth of the contents. The authors break the chapters into very self-contained topics including best practices and initial investigations, strace and system call tracing explained, the /proc filesystem, compiling, GDB (GNU Debugger), Linux system crashes and hangs, and kernel debugging, among others. These chapters are filled with detailed examples that perfectly illustrate real world scenarios that any Linux user will be familiar with.

Chapter 1 is an overview of the complex process of problem determination and resolution and begins with steps to configure your Linux system(s) for optimal troubleshooting. The authors outline a selection of tools they recommend the reader/user install on their Linux system(s) in anticipation of future problems: strace, ltrace, lsof, top, traceroute/tcptraceroute, ping, hexdump, tcpdump/ethereal, GDB and readelf. These and many others are categorized by type (process information and debugging, network, system information, files and object files, kernel and miscellaneous) in Appendix A, "The Toolbox." Wilding and Behman stress the importance of balancing the need to solve issues immediately vs. building troubleshooting skills. They outline four phases of problem investigation (using your own knowledge and skills to investigate, using the Internet, conducting a deeper investigation, and getting help) and discuss where the various tools fit into different scenarios, how to collect information about system changes, what resources are available on the Internet (Google, USENET, Bugzilla, etc.), how to handle more difficult problems and where and how to get outside help, if necessary.

Chapter 2 explains system call tracing, introduces the strace tool (traces system calls between a process and the kernel) and how to use it to diagnose errors related to the operating system. This is a very well organized chapter with plenty of depth. Wilding and Behman offer an extensive discussion of this first tool, progressing from simple examples that illustrate how to read the strace output, how/when to use strace options, timing system call activity, tracing an existing running process, to many practical debugging examples.

Chapter 3, "The /proc Filesystem," looks at user process information (/proc/self, /proc/<pid>, /proc/<pid>/environ, /proc/<pid>/mem), kernel information and manipulation (/proc/cpufreq, /proc/cpuinfo, /proc/devices, /proc/meminfo, /proc/partitions), and system information and manipulation (/proc/sys/fs, /proc/sys/kernel, /proc/sys/vm). The authors run through files and directories relative to /proc and describe how to view information about the kernel and currently running processes. This chapter gives a good example of how to use the "kernel magic sysrq key" feature (using the ALT-SysRq hotkeys to get kernel information) when a system hangs. Output from the commands showPC, showMem and showTasks are given as examples.

The next chapter details the GCC (GNU Compiler Collection) and compiling. The authors don't attempt to walk the reader through basic kernel source compiling but rather they concentrate on how to decipher errors that arise from compiling source. They give a basic outline of some basic compile failures (environment/setup errors, compiler version differences, user error, code error, etc.) then show a common error involving both incorrect code and different allowances made between compiler versions. Wilding and Behman show the reader how to decipher the kernel error and how to use both existing documentation and bugs posted on the Internet to correct the errors and rerun the compilation successfully. This is a very practical demonstration of how compile errors can be worked out and solved quickly.

Chapter 5 begins with a definition of "stacks" and a description of stack structure, local variables, and stack frames. Also shown is how to display the raw stack in a debugger like DDD (Data Display Debugger) or GDB (The Gnu Debugger) in order to perform a detailed stack analysis. The authors use the backtrace command to look at stack traceback output from GDB, "walking the stack" (manually walk the raw stack frame by frame using the dladdr function), common causes of stack corruption, and SIGILL signals.

Debugging applications is the subject of the next chapter with the majority of the chapter dedicated to The GNU Debugger. This is a logical place for a discussion on debuggers as the authors point out that they are particularly useful when problems can't be solved through log files, error messages, etc., when a problem is of an immediate nature (i.e. doesn't extend over a long period of time) and when source is available. GDB command line editing is covered along with how to control a live process by running the process directly through the debugger, how to attach to a running process and how to use a core file (or a process image) to perform debugging. The authors also examine viewing the memory map and variables, looking at the contents of register dumps, working with C++ (inline functions and exceptions), and problems with threaded applications. A brief description of the Data Display Debugger (DDD) GUI front-end to GDB is included at the conclusion of the chapter.

Chapter 7 deals with "System Crashes and Hangs" and how to assemble the appropriate information necessary to troubleshoot a system problem using various tools and techniques: using the syslog, setting up and using a serial console, using the SysRq kernel magic hotkey, examining the oops report generated by a manual kernel trap, considering hardware failure issues, and setting up cscope to index kernel sources. This chapter prepares the reader for documenting proper and extensive details about errors and problems not only for rapid diagnosis but also in the event he or she needs to call in an expert.

Kernel Debugging with KDB is a brief chapter that instructs the reader on how to enable and activate KDB, basic commands associated with its use, and some examples on how to use it. Several good illustrations of where KDB proves useful over other tools are included.

The final chapter explores the ELF file format (executable and linking format) for shared libraries and executables. The authors provide a comprehensive look at the ELF standard on Linux. They start with basic definitions and concepts (symbols names and C versus C++, linking with static libraries and run time linking, and run time linker) and prep the reader with some source code that is used in later chapter examples. They examine the ELF file structure (the header using hexdump, segments/sections with readelf, the program header table, and the section header table). This is probably the strongest chapter in the book. There is enough information and instruction in this chapter to arm a Linux system troubleshooter to follow the practical examples with little effort.

The book concludes with two valuable appendices that detail the authors' selected tools for Linux problem determination and include a data collector script intended to capture basic critical system information in the event of a problem. As discussed above, the "Toolbox" appendix is a summary of the authors' selection of best Linux tools for diagnosing problems. Each tool has a brief description, where to get it, level of usefulness, when to use the tool and additional notes. Appendix B, "Data Collection Script," offers the reader a sample bash script tool that gathers a broad range of system information. The authors provide several optional switches to increase the amount of data collected with the caveat that time to collect that information also increases.

Wilding and Behman assume some familiarity with the Linux system: their advice and instruction are intended for those users who are not afraid of the CLI and who understand basic Linux operating and file system structure. That said, Self-Service Linux: Mastering the Art of Problem Determination is a valuable resource for advanced users and system administrators. In short, this book is for anyone who uses Linux on a daily basis on one or multiple systems. The examples are fully detailed: the reader gets commands, options, output, sample code, and a variety of possible outcome scenarios. Wilding and Behman set out a realistic and practical approach to problem solving; they satisfy the troubleshooter in all of us. Self-Service Linux is a welcome addition to the Bruce Perens Open Source series of Prentice Hall PTR professional reference books."

You can purchase Self-Service Linux: Determining Problems and Finding Solutions from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Craig Maloney writes "By now most readers have probably heard about Firefox, the Open Source browser that poses a serious challenge to Internet Explorer. They've probably even installed it on a few machines, and no doubt have customized it pretty much to their liking. They're pretty comfortable with how it works in their day-to-day browsing activities. Plus, Firefox is pretty open, and about:config, extensions, and themes have many pages dedicated to their use. What more could there be to Firefox? Firefox Secrets is a collection of tips and tricks to help wring out that last kernel of performance from Firefox, with specific ways to increase users productivity with Firefox. It also contains plenty of tips for new Firefox users to guide them to learning what Firefox is, and how it can improve their browsing experience." Read on for Craig's review. Firefox Secrets author Chean Chu Yeow pages 297 publisher Sitepoint rating 8/10 reviewer Craig Maloney ISBN 0-9752402-4-2 summary Firefox tips and techniques for new and experienced users.

Firefox Secrets presents the material in a well thought out manner. Each chapter starts with a specific task in mind, with helpful tips in performing that task listed throughout the rest of the chapter. In the chapter entitled "Revisiting Web Pages" (something we are all bound to do at some time in our lives), Firefox Secrets starts the chapter with sections on importing bookmarks from other programs, creating new bookmarks, and using the bookmark manager. (Pretty basic stuff which most Slashdot readers have no doubt mastered). The power, though, lies in the rest of the chapter, where the book lists out how to add a bookmark for a group of tabs, how to create several types of keyword bookmark, how to use the bookmarks tool bar, and how to use the bookmark manager and sidebar. It then talks about Firefox's RSS and Live bookmarks, and how to create them using the RSS icon, and create them manually. Finally the chapter finishes off with the cookie and history managers, as well as the password manager. Each section is described in detail with clear directions on how to use the feature, and clear explanations on why readers would want to use the feature.

Expert users need not worry, though, as this book has plenty for them too. One of the more powerful features of Firefox are the Extensions, which allow incredible recognizability in Firefox. The chapter on Extensions starts with an introduction to what Extensions are, and why they're so important. Next the author describes installing an extension, and uses the miniT extension (an extension that allows drag-and-drop tab placement) as a sample extension to install. The author begins by directing the browser to the extensions site, installing the extension, and configuring the extension once the browser has recognized it. From there the author discusses installing from sites other than the Mozilla Extensions site, installing from a local file, and using the extensions manager to track and configure extensions. As someone who has installed many extensions that proved less than useful, or prevented Firefox from even starting properly, the next section on uninstalling and entering Firefox's safe-mode could prove profile-saving. (I have had several occasions where knowing about safe-mode would have saved me a half-hour's work in rebuilding my profile). The author moves from this introductory material to a list of his personal favorite extensions. Unless the reader has an RSS feed tuned to the Mozilla Extensions site, there's bound to be several extensions that the reader will find useful. (I downloaded the Spellbound Spell Check, and Download Status bar extensions during the course of this review).

Of course no book on the secrets of Firefox would be complete without mentioning about:config. about:config holds a treasure-trove of configurable options for Firefox, many of which are not self-evident without a guide of some form. Firefox secrets does not provide a comprehensive look at about:config, but instead shows what about:config is, shows how to use it, and presents a few neat tips that can be set by about:config. Other somewhat hidden preference features include the .css and .js files under the user profile. Firefox Secrets quickly glosses over some key tips, such as CSS examples for marking unread tabs, and shifting the sidebar to the right. Also included are tips for customizing the user interface, and incorporating web development features which developers will no doubt find extremely handy in their daily development rituals. The book finishes off with best practices for downloading and using the Firefox nightly builds, and what sorts of issues to expect.

Some people out there may feel that Firefox Secrets doesn't offer any tips that can't be found on the web. It's a fair assessment that some of the ideas presented in the book should be pretty routine for expert Firefox users. However, unless you have RSS feeds to every Mozilla development site, and maintain an encyclopedic knowledge of every configurable doo-dad and Extension, you'll likely find many good tips and best practices for enhancing your browsing experience. I'll admit I was skeptical this book would provide me anything of value, and I've been pleasantly surprised at how insightful this book is. Firefox Secrets balances between beginning users who have yet to install their first extension, and experts who want to take their browsing to the next level."

You can purchase Firefox Secrets from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

jsuda writes "Core Web Application Development with PHP and MySQL is an intermediate to advanced-level guide for programmers and developers. It bills itself as >everything one needs to know about building robust database applications. That is a bit of puffery but this is a comprehensive practical guide for designing and building production-quality, database-enabled applications." Read the rest of John's review. Core Web Application Development with PHP & MySQL author Marc Wandschneider pages 912 publisher Pearson Education rating 8 reviewer John Suda ISBN 0131867164 summary Fine strategic overview

The author is an open-source platform expert and software developer. He comes from a background of working with standard desktop Windows-based applications and made the transition to building dynamic web applications. His experience in making the transition informs this book as a comprehensive explanation of how to use the various technologies that go into writing web applications. For those making similar transitions, this is a very fine presentation done by a thoughtful, systematic designer. For those already busy in the PHP/MySQL area, the advanced level of instruction is likely to be valuable.

The emphasis is on open-source applications, particularly PHP5 and MySQL in an XHTML/Javascript environment. But, beyond technologies, the author's focus is on the strategies and systematic approach one needs to design and implement successful web applications. He writes for an advanced audience which is already basically familiar with programming and XHTML. Those writing or planning dynamic web applications will benefit most from the book.

There are 33 chapters in five parts - basics of PHP, database basics, planning web applications, implementation, and sample projects. There are three appendices covering installation and configuration of PHP, MySQL, and other related open-source applications like Apache, a set of charts of database function equivalents among the leading database types - MySQL, Oracle, PostgreSQL, Microsoft SQL Server, and a short list of recommended reading.

This is a large format book of 912 pages, including index. My reviewer's copy is a prepublication version containing grayscale graphics and much white space, especially around the code snippets, making reading easy and comfortable. Although the material is high-level and technical, the writing seems light and casual. Wandschneider's writing style flows easily, never bogs down even with technical details, and the book reads much faster than one might expect.

Although the best part of the book contains the three start-to-finish sample projects at the end - a calendar system, weblog engine, and e-commerce store, the lead-in chapters are nicely done, too. Chapters 1 and 2 are about getting started in PHP. There is a brief comparison to perl and C++, but the bulk is about PHP terminology and programming concepts. Much is made of PHP5's new object-oriented features, but the discussions of that here (and in Chapter 4) was about the only parts which I feel needed more clarity - the rest of the chapters are very clearly stated and contain plenty of good examples.

Chapters 3 - 7 continue with scripting concepts like functions, classes, arrays, strings and characters. The discussion is not designed to instruct comprehensively about PHP itself but works on a higher level of showing how PHP interacts with MySQL and other technologies on an overall basis. You can get detailed PHP coding instructions elsewhere. Chapter 6 contains an unusually good discussion of character sets, usable for global applications, and provides instructions on configuring Unicode and multi-byte support for high-level applications.

Part 2, Chapters 8 - 12, take the same approach to MySQL and databases in general. They include discussion of basic terminology and concepts, designing and creating databases, storing and retrieving data, PHP-to-database connectivity, and advanced topics, like use of "transactions" and advanced querying.

Part 3, Chapters 13 - 17, deal with the server-side matters. Again, the level of presentation is not on comprehensive details of PHP, MySQL, and web services, but present a comprehensive overview to guide planning, design, and implementation. Here the author states overall design considerations of a website noting how to incorporate CSS, HTML, code libraries, user interfaces, and web services into a working dynamic website.

User management and security concerns are noted throughout the book and Chapters 14 - 17 deal specifically with validation, and software and hardware security, including tips on how to secure your server. These passages on security are some of the better and clearest written I've experienced in this area.

Part IV continues the systematic approach to website construction discussing error handling, debugging, cookies, and sessions (again some of the clearest explanations I've read), authorization, and data validation with regular expressions. Chapter 21 is entirely about globalization and localization that is, dealing with the fact that the Internet is global and that there is a need to deal with foreign language sets. There are tips on how to determine users' locations and how to script to account for different language sets, including Unicode.

Chapters 23 and 27 are about XML and are especially useful now that XML and XHTML are becoming the reigning protocols of dynamic web activity. There is an extensive sample of using XML to work with the Google API. Using XML with PHP is an advanced topic and it is only generally covered here, together with XML web services and SOAP. Other chapters cover the use of extensions to PHP, like PEAR, developing a coding "style", creating test suites, configuring PHP.ini, and more. The three working examples are extensively commented and contain complete code examples.

The book comes with a comparison CD-ROM containing all of the sample code, and versions of PHP5, MySQL, and Apache HTTP server."

You can purchase Core Web Application Development with Php & MySQL from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

brainee28 asks: "I work in the IS department for a manufacturer in Arizona (a one-man-show). I do mostly everything; from systems, to networks, to procurement, to implementation. I can't mention who I work for since we deal with government contracts. My problem is this: The company didn't start out with an IS department. Up until 6 years ago, a few computers were scattered around, but processes and business was still being done the old-fashioned way (with paper). When the IS department was started, it was started by a hobbyist (he was named IS Manager before I showed up), who knew nothing about management or any of the major issues that befall a traditional IS dept. I joined 6 years ago (I have 5 years of IS Management experience, and 15 years of experience with IS in general) with the idea that I would be managing day-to-day operations. That has still not come to pass. The hobbyist left the company 4 years ago, and I've been on my own ever since." What is the best way for new IS managers to convince their superiors of the need for widespread change? "Management views IS as a facilities function; computers are a tool, and only a tool. I presented a proposal to them about 2 weeks ago which completely negates that and several other ideas they've had about IS. Management accepted the proposal; however I'm now faced with additional mountains to climb.

I have 3 things that management and I currently don't see eye to eye on:

1) The main job of IS is connectivity. Connectivity is the core of why we have IS. Anything else is extraneous, and I shouldn't be dealing with it.

2) IS involvement in other divisions isn't necessary. IS is involved with other divisions when physical products get connected to the network, but not before. Software should be evaluated by IS only when it becomes necessary for purchase and implementation, not before. Any developed piece of software (we have an in-house programmer in accounting who uses Access -- I know, I know...) should be evaluated by IS when the software is ready to install.

3)I'm too overloaded. With 93 permanent users and 110 workstations (some are floaters), I can't do both systems work and admin work (my title is Systems Administrator, but I carry no management authority) on my own. My proposal stated the need for the creation of staff (a tech and a clerk). Management thinks because things are running, I have no issues, but I'm falling apart from all I have to do to keep things running. I need to offset the load so I can do more of the 'bigger picture' things to help guide this company out of the IS dark ages. (We have no CTO or CIO; Management is made up of engineers from different disciplines)

How would Slashdot users attack this? I've done my Google searches; went back to traditional books from Barnes and Noble; and even contacted my alma mater, Northern Arizona University, to find some answers. How would you prove the need for change on these three points? Can I institute change here?"

FrazzledDad writes "Network geeks and developers working in the TCP/IP domain are most likely familiar with Douglas Comer's Internetworking With TCP/IP Vol.1. Comer's book was central for my understanding of how things really worked in the small corner of a world-wide network I use to manage. Charles Kozierok's The TCP/IP Guide has knocked Comer's book off my shelf. Kozierok's weighty book (1600 pages!) does a terrific job both as a reference and as a learning aid." Read on for Jim's review. The TCP/IP Guide: A Comprehensive, Illustrated Internet Protocols Reference author Charles Kozierok pages 1616 publisher No Starch Press rating 9/10 reviewer Jim Holmes ISBN 159327047X summary Amazing broad, deep coverage of TCP/IP in an understandable fashion.

Kozierok spent at least four years working full-time on this book, according to the dedication, and it shows. He covers everything from networking fundamentals to individual application protocols such as Gopher.

Do you need to familiarize yourself with Open Shortest Path First (OSPF) routing protocol basics? It's covered. Do you need to understand the pros and cons of Network Address Translation, and how static and dynamic mappings work? It's covered. Do you want the nitty gritty of how message formats are laid out? It's covered.

Kozierok also presents several chapters specifically on IPv6, laying out changes in the new version before diving into the nuts and bolts of it. He discusses the major additions, and dedicates an entire chapter to the new addressing scheme. The transition from IPv4 to IPv6 is a well-written section talking about the difficult conversion between the two versions.

THE BOOK AS A LEARNING GUIDE

TCP/IP can be a rather dry topic to read about when trying to learn portions of it. Let's face it: reading about BOOTP's messaging over UDP is not something most folks will give up a Friday night on the town for. OK, Kozierok's writing style won't make that happen, but he does keep things interesting and flowing well enough that working one's way through such topics is actually entertaining instead of torture.

For example, Chapter 18's discussion of subnetting concepts lays out the fundamentals in clear order without sliding into unfathomable academic blabberspeak. His use of "Key Concept" boxes throughout the book helps point out important items.

Just as important to the book's clarity and usefulness are the amazing graphics. In the Acknowledgments Kozierok specifically thanks the folks at SmartDraw.com for their illustrating package. He's put the tool to fantastic use for everything from breaking out the control bits from a TCP segment header to showing how iterative DNS name resolution works.

THE BOOK AS A REFERENCE

The level of detail in the book makes it a valuable reference in addition to its role as a learning guide. For example, readers can find specifics on details of SNMP data types, NFS server procedures, or TCP segment format layout. Additionally, Kozierok discusses many of the various TCP/IP utilities, such as using "netstat" for troubleshooting with a detailed discussion of various outputs.

Kozierok must have spent a lot of time figuring out how to best lay out the book, and it pays off with sensible organization. Two tables of content, one brief and one detailed (32 pages!), help one to get to the right spot to look up needed information. The index is nearly 50 pages and seems to be quite exhaustive; another great tool for getting to the right spot. There are also comprehensive lists of Figures and Tables if you're trying to access something via that route.

WHAT IT DOESN'T COVER

Kozierok is upfront about things he's left out of the book. You'll need to look elsewhere (back to Comer's book, perhaps) for details on TCP/IP in ATM networks, security and firewall design, and the lower levels of socket usage.

CONCLUSION

To me, a significant advantage of this book is No Starch's binding system that they make so much hay about. I can open this massive book to any point and leave it flat on the table. Pretty impressive!

Kozierok also has a companion website (www.TCPIPGuide.com) with errata, a FAQ, and various other areas. You can also purchase an electronic copy of the book.

The TCP/IP Guide is a tremendous work, and it's a significant resource for anyone working with TCP/IP."

You can purchase The TCP/IP Guide: A Comprehensive, Illustrated Internet Protocols Reference from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Michael J. Ross writes "The typical computer program has more bugs than there are ants at a picnic -- except ants are usually easier to find. Programs written in Perl are no exception, because the compactness of the language does not make any existent bugs easier to spot; they can simply be packed into fewer lines of code. To help remedy this problem, Richard Foley and Andy Lester, two seasoned Perl programmers, offer a new book, Pro Perl Debugging: From Professional to Expert." Read the rest of Michael's review. Pro Perl Debugging: From Professional to Expert author Richard Foley with Andy Lester pages 269 publisher Apress rating 8 reviewer Michael J. Ross ISBN 1590594541 summary A comprehensive tutorial and reference for the Perl debugger

This title was published in hardcover in March 2005 by Apress, a relatively new member of the technical publishing world. The publisher has a Web page for the book that includes links to all of the source code in a Zip file, the table of contents in PDF format, and a form for submitting errata. The book comprises 269 pages, the majority of which are organized into 16 chapters: Introduction (not to be confused with the true Introduction immediately preceding it), Inspecting Variables and Getting Help, Controlling Program Execution, Debugging a Simple Command Line Program, Tracing Execution, Debugging Modules, Debugging Object-Oriented Perl, Using the Debugger As a Shell, Debugging a CGI Program, Perl Threads and Forked Processes, Debugging Regular Expressions, Debugger Customization, Optimization and Performance Hints and Tips, Command Line and GUI Debuggers, Comprehensive Command Reference, Book References and URLs.

For programmers who wish to learn how to fully utilize Perl's debugger, what options are open to them? A terse summary of the debugger's commands are always close by, within the debugger itself. Those Perl coders who have yet to try the built-in Perl debugger, really owe it to themselves to give it a whirl. In most cases, it is superior to embedding lots of "print" statements in your scripts, and then wading through the results. Simply include perl.exe's -d flag on the system command line, and you should be put right into the debugger, and see the debugger's "DB<1>" command prompt -- the "1" meaning that it is ready for your first command. To display the aforementioned command summary, simply enter "h", or "|h" to see the output one screen-ful at a time, which you will probably want to do unless your system window can show all of the dozens of lines at once. The command summary is best used as a quick reference, and naturally cannot be expected to serve as any sort of tutorial. Yet it has its use, and for that, it's fine.

Most Perl books devote at least some space to explaining the basics of firing up and using Perl's debugger. The (in)famous "camel book," Larry Wall's Programming Perl, has a chapter on the debugger. It covers breakpoints, running, stepping, tracing, displaying code, commands, debugger customization, debugger options, unattended execution, creating your own debugger, and performance profiling. Aside from that last topic, the chapter is mostly an expansion of the command summary mentioned earlier. It is sparse on examples, and does not cover any advanced topics, such as using the debugger in the context of forking, threads, and POE, as well as the debugger's special capabilities for regular expressions, CGI programs, and shelling out.

The advanced topics are where Pro Perl Debugging really shines in relation to the coverage that I have seen in any other book, partly because the authors have the space to thoroughly explore those topics in depth, and to provide much more meaty examples, with adequately illustrative sample code. Even for the more complex topics, the writing is clear, and the examples are worthwhile.

The authors clearly intend for the book to serve as both a comprehensive tutorial and a reference for the Perl debugger. In both respects, they succeed admirably. But the practical value of their accomplishment could be called into question by any programmer who has grown tired of the limitations of the Perl debugger, and has switched over to any Perl-capable standalone GUI debugger or integrated development environment (IDE). More specifically, watching a variable change value, while stepping through the lines of a Perl script using the debugger, requires that the programmer manually or programmatically echo that variable's value, by issuing a print command ("p") followed by the variable name, one way or another. This process quickly becomes tedious when multiple variables need to be watched, because each individual variable must be printed, one at a time. Admittedly, previously entered print statements can be recalled by using the up-arrow key, but only if the particular command has not been pushed out of the debugger's limited storage. This usually becomes even more frustrating when trying to print the values of indexed arrays, hashes, and nested arrays and other structures. There are workarounds, but none are pretty, and even the most promising techniques still seem to require excessive focusing on the debugger commands themselves, drawing attention away from the code being debugged.

As a result, some disheartened Perl coders eventually switch back to embedding "print" statements in their code. Fortunately, there is a better alternative, in the form of IDEs, which can automatically report the changing values of a large set of variables, none of which need to be typed in, owing to the drag-and-drop capabilities of most IDEs. There are many IDEs available, including freeware and open source offerings. Most if not all of them support advanced editing, syntax highlighting and verification, visual breakpoints, and other much-appreciated capabilities. Even if they were to lack all of these features, and only have the advantage of easily and dynamically displaying the current values of variables, then they would be much more pleasant to use than the built-in Perl debugger. This is especially true in the case of nested structures, which can be expanded with a mouse click within most IDEs. All of this being said, it should be noted that the authors include a chapter that briefly touches upon the most well-known Perl GUI debuggers -- but at only seven pages in length, the chosen applications get only a cursory treatment, highlighting their major features.

Nonetheless, given the intended purpose of Pro Perl Debugging, and its target audience, the book cannot be faulted for its contents nor its approach to presenting the material. Anyone looking for a detailed and competent explication of the native Perl debugger, would likely not be able to find a more thorough treatment anywhere else.

Michael J. Ross is a freelance writer, computer consultant, and the editor of PristinePlanet.com's free newsletter."

You can purchase Pro Perl Debugging from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Bill Ryan writes "Sarah Morgan Rea's "Building Intelligent .NET Applications" is a book for those that get easily bored with mainstream development topics. Essentially, it's an in depth discussion of 3 niche technologies that came directly out of Microsoft Research (Microsoft Speech Server, Microsoft Analysis Services and Agents). The majority of the book is comprised of discussions of the first two technologies with roughly 12 pages being dedicated to Agents. It's finished off future Microsoft technologies "Avalon" (now known as the Microsoft Presentation Framework), Indigo, WinFS and Longhorn. Fortunately, since no one really knows when Microsoft will deliver each of these and what they will ultimately look like, she spends under 10 pages on them." Read the rest of Bill's review. Building Intelligent .NET Applications author Sara Morgan Rea pages 270 publisher Addison-Wesley rating 9 reviewer Bill Ryan ISBN 0321246268 summary

One of the things that makes this book great is that each of the areas discussed receive very little discussion elsewhere. If you want to use Microsoft Speech Server, you are essentially confined to using the SDK documentation, the MSDN newsgroups or an occasional blog post out there. Analysis services has a little more documentation but if you were looking to do any serious A.S. development, you're still pretty hard pressed to find comprehensive resources on how to use it.

These two areas comprise roughly 80% of Sarah's book. The discussion on Speech Server comprises a little over 100 pages and does an excellent job showing you how to get Speech Server up and running and how to use it. She starts out slowly and walks you through the Speech SDK, then moves on to creating Grammars, creating Prompts, creating Transcriptions and Extractions, using the Telephony modules and debugging/performance tuning your applications. Another nice touch is that she spends a good bit of time discussing more agnostic elements of speech and telephony development, S.A.L.T. in particular. Within the discussion throughout, there's a good bit of attention paid to configuring Speech Server and the problems people are typically confronted with when they create speech enabled apps. However she does a pretty good job of balancing the introductory material with more advanced topics for although she does spend a lot of time on setup and configuration, she also goes as far as showing you how to use Speech Server from a PDA.

As far as speech (the topic goes), it would be helpful if the reader had some familiarity with the core concepts involved (such as SALT, Grammars etc.) but even if you didn't, this book would still help teach you a lot of what you'd want to know. The intended audience is clearly intermediate to advanced developers but newbies will definitely find quite a bit of valuable information in it.

The next section discusses Artificial intelligence in the context of Analysis services. If you aren't familiar with relational database concepts, then it's probably a little above your head, but most people buying this book aren't running into relational database theory for the first time.

Chapter 5 starts with using Data Mining to create predictions. It starts with getting things set up, moves onto building the data mart, and then finally 'training' the model. This discussion is pure gold in my humble opinion.

The next chapter moves on to applying those predictions. Not really much to say here without getting overly technical but essentially this chapter is a walk through of what you'd do after you had your data mart built and trained, essentially, how you'd maintain it and continue to refresh the information.

This is followed by a chapter titled "An Evolving Database". Again, this is pretty technical in nature so it's hard to describe without bogging you down in jargon. Suffice to say that everything about this section is cool++; .

The book then discusses Agents, which are cool but probably don't have that much applicability in most people's day to day lives. If you want to learn how to use them (as well as the Background Intelligent Transfer Service), then she provides everything you need.

Finally things wind down with a discussion of Microsoft's upcoming technologies, Microsoft Research, Artificial Intelligence in general (as well as many resources on where to learn more), a glossary, bibliography and finally the index. Discussing any one of the areas that she touches upon here (neural networks, Fuzzy logic, natural language processing, machine learning etc.) could comprise an entire book. That's where the beauty of this book comes in - instead of discussing the subjects one at a time, she creates a series of walk through examples where she creates specific scenarios and shows you how to address them using each respective technology.

If you're bored and want to dive into some really cool subject matter, this book is a must have. If you want to learn more about Speech technology in general and Microsoft's implementations of it in particular, this book is a must have. If you're interested in artificial intelligence again, you'll find this book to be superb. If you just want to learn about subject matter that's been discussed over and over again, like creating Winforms or drawing with GDI+, then this book probably isn't up your alley."

You can purchase Building Intelligent .NET Applications from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

jsuda writes " With all the books being published recently about PHP a new one will need to find and fill a niche to distinguish itself. PHP 5 Recipes: A Problem-Solution Approach, published by Apress, has done so, in my view. This is an intermediate-level volume exploring PHP 5 using a recipe approach where the basics of PHP 5's functionality are expressed systematically but in a small-topic by small-topic manner. Cook-book style, each topic is relatively autonomous and can be individually selected, as necessary, for information or review, similarly to how many refer to the Joy of Cooking for help on a cooking project. It's a source for instant solutions to common PHP-related problems. There are over 200 such recipes presented." Read the rest of jsuda's review. Php 5 Recipes: A Problem-Solution Approach author Lee Babin, Nathan Good, Frank M. Kronman, Jon Stephens pages 646 publisher Apress rating 8 reviewer John Suda ISBN 1-59059-509-2 summary A problem solving approach to Php 5

Each of these recipes refers to a small element or aspect of PHP 5 and the presentations contain a brief overview of the topic, an explanation of how the code elements work, and where the code is applicable in projects. Overall, the book covers the whole range of PHP 5 functionality where each major element of PHP 5 is addressed in a recipe explaining and illuminating relevant code elements. You can easily get information about a specific PHP 5 element by going directly to the section of the book where it appears. Even better, the code snippets are designed to allow one to copy and paste them into your own applications or development easily and then to configure them as necessary. All of the code snippets are freely available for downloading at the publisher's website at www.apress.com.

There are 16 chapters and an index covering a total of 646 pages. The chapters are organized similarly to other PHP primers, covering the basic elements of PHP - data types, operations, arrays, strings, variables, files and directories, dates and times, functions, and regular expressions. The coverage for much of these concepts is relatively mundane and unoriginal. The discussion of dynamic imaging, however, is an exception. The writing throughout, however, is solid and clear. The book emphasizes the most important elements of new PHP 5. The object-oriented programming elements especially are covered - classes, objects, protected class variables, exception handling, interfaces, and the new mysqli database extension. The authors' discussions focus on PHP 5.0.4, MySQL 4.1, and cover Linux and Windows environments.

The book is directed at PHP programmers looking to learn the elements introduced by PHP 5, and for those looking to find fast solutions to coding problems. It assumes a basic knowledge of PHP. Many of the recipes discuss object-oriented programming and these are some of the more advanced sections of the book. I can say that Chapter 2, which introduces the object-oriented concepts is one of the better explanations of the topic that I've read. The chapter covers constructors, destructors, methods and properties, class diagrams and examples of these concepts at work in code snippets. There are a number of interesting segments containing custom coding of classes as reusable templates from which to create objects.

The book is well-designed and written. The discussion is clear and logical. The code snippets are well-explained. The authors are experienced programmers and developers, and Good and Stephens have authored or co-authored a number of technical books.

A large handful of the recipes contain projects, usually appearing at the end of the overview and presentation of code snippets covering the basics of the topics. The projects usually deal with the creation of higher-end classes and objects as solutions to common coding problems. The idea here is to show PHP 5 functionality at work providing useful code sections to be dropped into your custom applications. Chapter Five concludes with a sophisticated class dealing with dates and times issues. Other chapters contain constructions of string, file, graphics, and regular expression classes.

The last five chapters deal with using the PHP code in web applications and services. This material covers cookies (including construction of a cookie class), using HTTP headers, sessions, and using query strings. Much of this material has been covered elsewhere in the many primers on PHP already published. There is a chapter on using forms and an interesting chapter on working with markup. The better chapters are on using DOM to generate markup, parsing XML, using RSS feeds, SOAP, and simple XML. The chapter on mysql is basic, except for the section on creating a wrapper class. The last chapter deals with communicating with Internet services, like POP, iMap, and FTP. Another project presented here is one creating object-oriented code dealing with a mail class.

This is a useful book to have in a programmer's library."

You can purchase Php 5 Recipes: A Problem-Solution Approach from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Graeme Williams writes "My experience with Visual Studio was several years ago, and limited to a support role. My only serious programming experience was more than twenty years ago, so I'm the kind of hobbyist programmer that Visual Basic 2005 Express and this book is aimed at. Microsoft Visual Basic 2005 Express Edition: Build a Program Now! doesn't attempt to teach you programming in general or Visual Basic in particular. It's focused on introducing the features of the Express Edition of Visual Basic 2005. I think this focus serves the book and the reader very well." Read on for the rest of Graeme's review. Microsoft Visual Basic 2005 Express Edition: Build a Program Now! author Patrice Pelland pages xi + 209 publisher Microsoft Press rating 9 reviewer Graeme Williams ISBN 0-7356-2213-2 summary An excellent introduction to Microsoft's new Visual Basic 2005 Express programming system

At the moment, the book is only available in PDF form as a free download from Microsoft when you register Visual Basic 2005 Express. According to Barnes & Noble, it will also be available as a paperback some time this month. The paperback will include a CD with both Visual Basic 2005 Express and SQL Server 2005 Express. This review is based on the PDF.

The PDF is an inconvenient form for an ebook. It's protected so that you can't create your own bookmarks, and Microsoft doesn't provide any, and there are no clickable links -- in the table of contents, for example. There's a menu item for find, but the text doesn't seemed to be stored as text, so find doesn't actually find anything.

The book starts off with brief descriptions of .NET, object-oriented programming and the new features in Visual Basic 2005 Express. I guess it makes sense as a general introduction, and you can skip it if you like. It's certainly not a thorough explanation of object-oriented programming, but it's enough to let someone know that there's more to learn.

The next chapter leads you through installing the software. This is of doubtful value, since it basically advises you to stay with the defaults, which you almost certainly could have done on your own. If you have a problem, the book points you to some online resources, but that's all. I had a problem because my 'My Documents' folder is on a server, and this was enough to break the default security settings. The installation offers to install SQL Server 2005 Express, but neither the installation nor the book tells you that this will leave SQL Server running all the time.

Once the software is installed, you can start programming. The examples in the book are great. Starting with a simple console application to add two numbers might seem silly, but it makes sense in Visual Basic 2005 because you can't just start typing – you have to start somewhere in particular, and you need to know how to do that. Following that, you build a Windows application to add two numbers, a web browser, a database application, and an application that retrieves data from a web service. Each example builds nicely on the one before, and they're functional enough to be useful in their own right.

As important as the examples is what you learn along the way about the tools that make up the Visual Basic 2005 system. The book shows how simple it is to use the built-in components in Visual Basic 2005 to add features and functions to your application including forms, buttons, menus, toolbars, a splash screen, an about box, web services and database connections. This is where the book really shines. It shows you very clearly how to take advantage of the time (and work) saving features of the system.

The book is pretty good at explaining how to design a form. Form design was just awful in previous versions of Visual Basic, but the book clearly explains the new features that make it a little easier. The system is still not perfect – you can't automatically create three equally spaced textboxes (input fields), for example – but that's not the fault of this book.

The book also does a good job explaining the mechanics of starting a project, building applications and libraries, debugging, and "publishing" your application. "Publishing" is what Microsoft calls the process of turning your completed program into an installer which anyone can run to install your program. There's also an excellent introduction to database tables and how to create and use them within the system.

The graphic design in the book could be better. Each step in the instructions is indicated by a large numbered green bullet, which works well when there are only a few steps on a page, but you can easily get lost when one page has ten bullets and five tables. Also, you spend a considerable amount of time setting object properties. The value for each property is shown in a table, but sometimes a single table will include more than one object and sometimes it won't, which can be confusing. Finally, the screenshots aren't very clear. These may seem like quibbles, but an introductory book has a responsibility to be as clear as possible, and then some.

As you work through the examples in the book, you can really feel yourself gaining momentum. The flip-side of this is that as you go through the book, you get less and less explanation for larger and larger chunks of code. The largest single piece of code is 56 lines long. In context, it's presented clearly enough that it's still easy to digest. One way of measuring the success of an introductory book like this is whether it gives you the confidence to keep going on your own, and I think this book does just that.

But what if you're new to programming? If you're an absolute beginner, this book won't teach you how to program in Visual Basic. For example, the book never mentions structures or recursion. You can't do any serious programming just with what you'll learn about programming from this book, but that's not its purpose. The instructions in this book ARE clear enough that you'll be able to follow along, but if you want to get the most out of this book you'll have to spend some extra time working through the examples and with learning the language, even if it's only via the online help.

On the other hand, I don't think you can know so much that this book won't be very useful. Microsoft in its wisdom changes terminology regularly (toolbar is now toolstrip??) and there are many new features in this version of Visual Basic, so it's a good idea to hire a guide.

Depending on your level of experience, you may need other resources to learn everything you want to about programming in Visual Basic 2005, but this is a great place to start."

You can purchase Microsoft Visual Basic 2005 Express Edition: Build a Program Now! from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

As more and more people realize the fun they're denying themselves by turning away from orc-bashing and dragon-baiting, mainstream businesses and media are paying more attention to RPGs. Sam the Giant writes "Barnes & Noble University is offering a free 8 hour on-line course titled 'Discover Dungeons & Dragons: Becoming a D&D Player'. The free course is described as follows: 'As a beginning player, this course will guide you in understanding how D&D works, explaining the various worlds and characters types that it is based on, creating a D&D role for yourself, and understanding how your player role interacts in the world and with other characters. You will learn the extent of your abilities and the possibilities that lie ahead for your player, including magical spells, mythic quests, and epic battles with incredible monsters.' It's free to enroll." In the same vein, NPR's great reporting turns to World of Warcraft. Dragoonmac writes "All Things Considered recently ran a feature about WoW communities, farmers, and a humorous review of real-life. A Slashdotter's must hear."

Ben Rothke writes "Noted security guru Marcus Ranum has observed that "these days, with the kind of plug-ins that come in your typical browser, combined with all the bizarre undocumented protocols used by new Internet applications; makes it highly unlikely that a firewall is doing anything more complex than a thin layer of policy atop routing. As such, the applications behind the firewall are now more critical to security than the firewall itself. Which should scare the holey moley out of you."" Read on for Ben's review. Cryptography in the Database : The Last Line of Defense author Kevin Kenan pages 312 publisher Addison-Wesley rating 9 reviewer Ben Rothke ISBN 0321320735 summary Excellent reference for those that are serious about securing their corporate databases

Taking Ranum's observation to the next level, it is not only the applications that need to be secured, but databases also. The theme of Cryptography in the Database - The Last Line of Defense is that databases, being the main repository for critical consumer and business data, are often not given the adequate level of security that they deserve.

Large databases often contain terabytes of data. This data often contains R&D, client, customer data and more, that if compromised, could wreak havoc on an organization; both from a public relations perspective, in addition to a regulatory perspective. In a large customer driven organization, a database breach can wreak havoc on tens of thousands of customer records. With all of that, companies will spend large amounts of money on the security appliance of the month, but often let their databases sit unprotected.

Cryptography in the Database is a valuable book in that it shows how a formal methodology is required to adequately protect large corporate databases. The emphasis of the book is on designing and integrating a cryptosystem into the database to protect it against the various threats that are specifically launched against corporate database systems.

The books 4 parts contain 21 chapters. Part one is brief overview of the need for database security, along with related threats to database, and also covers the basic concepts of cryptography and encryption.

Part two provides a comprehensive synopsis on the cryptographic infrastructure necessary to secure corporate databases. Chapter 3 goes into details on how to set up an effective key management scheme. Such a scheme is crucial as the author notes that all it takes is the loss of a single 128-bit key, and gigabytes of data can become inaccessible.

Part two also creates a sample cryptographic architecture that is flexible and modular so that it is easily adaptable to various situations. The author notes that such systems can be difficult to manage if they become overly complex, and the challenge is to find the right balance between security and complexity on one side, and usability on the other. Creating an effective cryptographic database infrastructure. is not an elementary task given the different requirements of security and functionality.

Chapter 3 details the various entities that go into a complete cryptographic architecture, including the cryptographic engine, and the various controls around the crypto keys. The chapter provides a good overview of the key life cycle. Historically, controls around the key life cycle are crucial. One of the ways the Allies were able to break the German Enigma cipher machine during World War II was that the German's reused their crypto keys, which obviates much of the security that cryptography can provide. Had the German's not done that, the outcome of the war may have been dramatically different.

Part 3 details the issues that need to go into the entire cryptography project. Kenan notes that for security to be effective, it must be dealt with at the commencement of a project and must permeate the overall design and seep into every line of code. Also, in the long term, developing a culture of security depends on looking at security as an opportunity to provide extra value. Where security fails is when it is viewed merely as a series of checklists that are meant to get in the way.

Chapter 9 shows how data flow diagrams can be used by a database analyst to better understand how a system works. These data flow diagrams are valuable as that they show the various inputs into the system and where potential failures can crop up.

Part 4 provides various Java code examples of the cryptographic infrastructure that were detailed in the previous 12 chapters. The example code is meant to show how to implement the primary functionality of the various components that the book describes.

One of the popular terms in security today is data at rest, which refers to all data in storage. Businesses, government agencies, and others need to deal with attacks on data at rest, which more often then not will be found on databases.

After reading Cryptography in the Database, the reader can understand why database cryptography must be implemented in a methodological fashion, since incorrectly implemented cryptography can often be worse than no cryptography at all. With that, database administrators, architects and others who have input into the design of database security are highly advised to read Cryptography in the Database.

Databases are far too critical to an organization to be left unsecured, or incorrectly secured. The database is indeed the last line of defense in an organization. Books such as this are thusly vital to ensure that the last line of defense is not easily breached.

You can purchase Cryptography in the Database from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Ben Rothke writes "Load up a computer today with a basic set of applications software, and there will be a de facto Microsoft tax on that computer. Add roughly $100- for the Windows XP operating systems and $350- for Microsoft office, and you have a significant initial financial outlay. If one would use an open source operating system and set of office applications, the cost savings would be enormous. That is why the option of open source is so financially compelling to the both the consumer and organizations have thousands of computers. And open source is corresponding such a threat to companies such as Microsoft. The idea of saving money and never having to worry about a blue screen of death is the proverbial win/win scenario." Read on for Ben's review. Just Say No to Microsoft: How to Ditch Microsoft and Why It's Not as Hard as You Think author Tony Bove pages 243 publisher No Starch Press rating 7 reviewer Ben Rothke ISBN 159327064X summary Open source alternatives to Microsoft operating systems and applications

With that, Just Say No to Microsoft: How to Ditch Microsoft and Why It's Not as Hard as You Think would seemingly be a most valuable book in helping consumers and corporations rid themselves of the Microsoft tax. Unfortunately, the book spends far too much time slurring Microsoft and Bill Gates.

The books main charges are that Microsoft has been far too predatory and that Bill Gates is not the technical genius that he is made out to be. Microsoft's questionable business tactics are not without ethical lapses, but it must noted that Microsoft is simply one in a long line of companies that have used their size and deep pockets to quash the competition. Microsoft is not alone and joins companies such as American Airlines, Ford and General Motors, Wal-Mart and more that have engaged in practices that while good for their stockholders, have not been good for the competition.

Bove is correct that Microsoft's practices over the years have discouraged innovation and stunted competition. But then again, that is true of Ford, GM and other such companies. The innovations of Ford and GM for example have been mostly superficial, without any significant improvement into crucial issues such as gas mileage and more.

Two of the companies that Microsoft has been accused of destroying are Novell and WordPerfect. Yet much of the blame for the demise of these two companies goes to their management that did not know how to properly market their products nor deal with a competitor such as Microsoft. This is not meant to imply that Microsoft is blameless, rather that Novell and WordPerfect had plenty of opportunities to fend off Microsoft, yet did not rise to the challenge.

Aside from the pervasive anti-Microsoft tone and style and the book, Just Say No to Microsoft: How to Ditch Microsoft and Why It's Not as Hard as You Think provides a good starting point for those that are looking for a cheaper and safer alternative to Microsoft products.

Chapter 1 start with an overview of the history of Microsoft and how it grew to be the largest software company in the world. In chapter 2, All You Need is a Mac, Bove feels that the quickest route to Microsoft freedom is by purchasing a Macintosh. While a Mac is not necessarily cheaper than a Wintel system, the Mac OS X is considerably more resilient against attacks. In addition, the concern of malware such as viruses and spyware are much less of an issue on a Mac.

Chapter 3 deals with what worries Microsoft the most - Linux. Bove notes that large companies that deal with thousands of end-user desktops are discovering the advantage of migrating to Linux in a big way.

Chapters 4 and 5 deal with Microsoft Word and Excel. Word documents have become the de facto standard for document exchange and are what has locked many people into staying with Microsoft Word. Excel has a similar power in being the de facto spreadsheet. Most people think that the only alternative to Word is WordPerfect and simply don't know about OpenOffice Writer and Calc or other open source alternatives. The two chapters show how it is possible to effectively collaborate on documents without having to use Word.

While the book does not get into every open source alternative to a Microsoft product, Bove's web site has a comprehensive list of open source alternatives to Windows products at www.tonybove.com/getoffmicrosoft/home.html#windows

Chapter 4 concludes with a look at the technical and practical problems with PowerPoint. Bove notes that the corrupting power of PowerPoint is so strong that otherwise normally articulate speakers turn into zombies mumbling the bullet points that appear on the slides behind them. It is not clear though how Impress, the open source alternative to PowerPoint is necessarily better from a presentation perspective.

The next few chapters deal with Outlook, the application that has launched countless viruses and worms, and also detail other network-based problems with Microsoft protocols and applications. Issues such as the never enduing cycle of Microsoft patches are also discussed.

Chapter 10 provides a 10 step program (fashioned after the Alcoholics Anonymous 12 step program) to free the reader from their Microsoft addition. While the steps are brief and effective, it would have been better had there been more technical details on how to migrate out of a Microsoft environment. For the person with thousands of documents and files in various Microsoft formats, it is not as effortless as to simply copy your old files onto a USB drive and move it to the new open source based host.

The book contains four parts, and there are four cartoons at the begging of each part that Bove wrote. The cartoons are quite funny in their own right and Bove should also consider a career as a cartoonist.

Ned Ludd said that the machine was the enemy, and Tony Bove feels the same way about Microsoft. For evidence, check out his campaign to stop the spread of Word documents at www.tonybove.com/getoffmicrosoft/stopdoc.html.

The only negative to the book is that there are far too many anti-negative stories of Microsoft's predatory practices. A few stories would be adequate, but there is no point in belaboring the issue in a book that is meant to be more technical and practical, as opposed to political.

For many people who don't know better, they expect that a blue screen of death and monthly patching is part of a standard computing environment. Just Say No to Microsoft: How to Ditch Microsoft and Why It's Not as Hard as You Think is an interesting read that will open the eyes of those users to a cheaper, more secure and robust open source solution.

You can purchase Just Say No to Microsoft from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

jsuda writes "Podcasting appears to be one of the more interesting developments in current culture and technology. It is one of the earliest nonbusiness representations of the value and power of XML (Extensible Markup Language). XML is subtly and quietly being used to link digital documents together, and more significantly, databases, much like the Internet itself linked individual computers into a global network." Read on for the rest of Jsuda's review. Podcasting Hacks: Tips & Tools for Blogging Out Loud author Jack D. Herrington pages 428 publisher O'Reilly Media Inc. rating 8 reviewer John Suda ISBN 0-596-10066-3 summary Good primer on Podcasting

The power of XML is yet to be fully recognized, but its expression in podcasting has far-reaching effects and consequences all by itself. Way beyond extending audio distribution over the Internet and providing relatively easy access for creative types to a global distribution channel, podcasting may alter and extend the distribution of content in ways never experienced before, having repercussions for political communication, social expression, and democracy itself.

Podcasting can be considered, in general, a melding of several elements: digital audio, weblogs, radio, Tivo-like recording/playing devices, and RSS (Really Simple Syndication). RSS is the protocol extending XML allowing creators to publish content to audiences who can easily subscribe and partake remotely in both space and time. It is much more than merely an alternative to conventional radio.

Given all of this asserted importance, the new book, Podcasting Hacks: Tips & Tools for Blogging Out Loud is perfectly timed to provide guidance on how to find, listen to, and subscribe to podcasts as well as how to create, publish, and market audio and video content. This is a comprehensive introduction to nearly all aspects of podcasting. It covers not only the technological elements but the content and creative elements as well. Much of the later material draws on analog sources like radio and television broadcasting. Many of the content elements are shared across the technology distinctions. Good interviewing techniques and content stylings, for example, are the same regardless of how produced and distributed. The major theme here is how to produce quality audio which can attract audiences via digital distribution over the now ubiquitous Internet.

The book has 11 chapters covering how to find podcasts, starting out in listening and creating podcasts, producing quality sound, using formats, interviewing, blogging, publicity, basic editing, advanced audio, mobility, and video blogging.

The main author is Jack D. Herrington, a software engineer and developer and technology writer and reviewer. There are 20 other contributors to the book, including journalists, multimedia consultants, radio and video producers, web editors, and podcasters themselves, particularly several who have popularized the medium.

The book has two main focuses - how to find and listen to podcasts and how to produce your own. The later focus consumes most of the book and deals with producing the best sound (with the lowest noise), producing interesting content, marketing, getting involved in the community, and even how to get your audio masterpieces into syndication.

Although this book is part of the venerable O'Reilly series of Hacks, the 75 "hacks" contained here work more like captions for various sub topics under the podcasting rubric. The book is less a collection of individually-packaged solutions to discrete problems or issues, but a primer on the whole of podcasting.

The first two chapters provide a list of the best and most popular podcasts, and directions on how to search directories of podcasts on the web. Apple's iTunes software broadly popularized podcasting only a short while ago by including a built-in directory of podcasts in version 4.9 of iTunes. How to get and use the right podcaster for your interests is explained, as well as some recommendations of specific applications - iPodder gets good reviews. Hack #2 offers a perl script which allows one to aggregate and rebroadcast feeds from other sources. Hacks 3 & 4 also describe perl scripts to build your own podcasts and to import podcasts into iTunes, (both PC and Mac versions.)

Using perl scripts is not for everyone, but the content of this book is fairly broad, having interest and value for a wide range of technological types, from higher level geeks to the person who is only casually interested in this new technology and content. Throughout, when discussing common software applications, the authors pointedly cover each of the main platforms - Windows, Mac OSX, and Linux and both technical production and content. Hack 10, for instance. is a technological hack; it relates how to create your first podcast using the freeware, Audacity. Hack 11 is a content-related hack instructing how to produce the content of a podcast and how to understand the respective roles of producer, writer, engineer, host, editor, and performer.

Surprisingly, one can get started producing podcasts relatively easily using a very modest amount of hardware and a little software, including mostly freeware or modestly-priced applications. The authors go out of their way in many of the hacks to point out how to select and acquire production materials at low cost. They often recommend specific products and services making it as easy as possible for readers to believe they can actively participate in podcasting with relatively modest efforts and budget.

The segments on formats describes what a format is in terms of duration, structure, content, and production elements. Some of the many types of formats are itemized and described - news, story show, personal show, political, mystery science theater, music, sports, technology, and news. The segments for each of these contains information on important sources for content, examples of use, and tips for producing content. Each type has its own strengths, limitations, and pitfalls. An overly enthusiastic personal show, for example, can get you fired from your job if your boss accesses and hears something he/she doesn't like. (It has happened more than once, according to news resources).

There is an enormous amount of material presented in this book with excellent attention to details. The audio theater type of format, for example, includes an itemization of the structure of a typical show - the story, script, studio setup, performances (with directorial prompts), mixing and encoding audio, and even how to make your own sound effects. Hack 33 describes techniques professionals use in producing interviews - types of interviews, location considerations, preparing guests, interviewing techniques, using environment sound ambience, and even microphone techniques. A large handful of the contributors make reference to how to use microphones properly emphasizing the need to control wind, voice pops, environmental noises and the like. There is even guidance on training one's voice for audio (Hack #19).

Virtually every possible element of podcasting is noted in this book. Some other topics include: how to record telephone interviews, including Skype conversations (#34); how to podcast using blogs (with examples of HTML and XML coding); how to manage bandwidth (#39); how to use ID3 tags for your audio to facilitate searches (#40); how to market, connect with the community, and even how to make money while podcasting (#48-49).

More advanced topics are handled later in the book. Learn basic editing using the right audio tools in Hacks#50-58. Hack 61 details how to set up a home studio. A very interesting section tells how to be mobile while podcasting including making a small recording rig for travel as well as podcasting directly from your car while driving. (Sounds unsafe to me and illegal in some states, as noted by the authors). Other sections take up, directly and at length, the legalities of podcasting covering copyrights, libel, licensing, and more. An interesting explanation of Creative Commons licensing is contained in #67 - 68. To cap it all off, there is a useful glossary of digital and analog audio terminology and an index.

As you might expect, given the presence of 21 contributors, not all hacks are as good as some, and there is considerable repetition of some elements, like microphone handling, production concepts, and others. However, these are small quibbles for such an information- packed volume of modest cost."

You can purchase Podcasting Hacks from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Simon P. Chappell writes "There's always a danger when a new technology buzzword hits the ground running. The danger is that when it finally slows down enough for us to take a good look at, it'll be found to be empty hype with less value than a mime performance on a radio show. This time the buzzword is Ajax and it's moving so fast that you can almost hear the sonic boom. The authors of Manning's new Ajax in Action have managed to catch up with Ajax long enough to take a look at it for us. Their book explains what Ajax is, how to use it and how, for once, the hype may be underselling the prospects for this new buzzword." Read on for Simon's review. Ajax In Action author Crane, Pascarello with James pages 650 (16 page index) publisher Manning rating 9/10 reviewer Simon P. Chappell ISBN 1932394613 summary If you want to create dynamic web applications, get this book.

The majority of the book is for programmers engaged in the development of web applications; especially those who are interested in taking their applications beyond the traditional ``click and wait for the response from the server'' model that we've become accustomed too.

The first section, and particularly the first chapter, would be suitable for anyone who is curious about Ajax. The first chapter answers the questions of what it is, and why it deserves all of the positive press that it's received. If you're introducing Ajax at work, this might be the chapter of recommended reading for your managers and software architects.

Alright, enough introducing the book, now let's take a look at just what Ajax is. Ajax itself is an acronym created by Jesse James Garrett in his, now classic, article Ajax: A New Approach to Web Applications. Ajax, we are told, means Asynchronous JavaScript and XML. This is our first clue that Ajax is not a single, new thing. Ajax actually turns out to be a combination of existing technologies mixed up in a fairly new way.

The fundamental ingredients in Ajax are in-browser JavaScript, Cascading Style Sheets, the browser's internal DOM model and asynchronous HTTP requests. Ajax, the technology, is the amalgam of these individual technologies. Thus, Ajax is both new and well proven at the same time.

Perhaps it's also possible to view Ajax as the natural resting place of the pendulum of application development. Programmers, since the beginning of application development have been trying to balance user experience and ease of installation and maintenance. First we had mainframes with their centralized usage model. Next we got the PC with it's entirely disconnected usage model. This was followed by the Client/Server model that tried to be connected yet offloaded it's processing to the client. The world wide web came next and browsers as the ultimate thin clients forced all of the processing back onto the server again. Finally now, with Ajax, we have what seems like a good balance of server side processing, with responsive clients that provide the rich user interface that users want. The pendulum of centralized versus decentralized has found it's rest point.

The structure of the book is fairly standard. The first section, three chapters, concentrates on imparting the concept of Ajax to the reader. The first chapter begins with the concepts, chapter two takes the reader through some very simple first steps, while chapter three explores how the Model View Controller pattern (MVC to it's friends) applies in the Ajax world and looks at third party, free and open-source Ajax libraries available today.

Part two of the book explores the core techniques of Ajax. Chapter four explores the difference between a web application and a desktop or Ajax application, that of a single page being the entire application. Chapter five explores the role of the server, looking at what resources are available for the server-side coding, including available languages and frameworks as well as ways and means of exchanging data with the server.

Part three looks at what the authors call ``Professional Ajax'', the techniques that make a difference when creating real world applications. Chapter six covers the design of the user experience. The user experience for a major application basically is the application for the user and so getting this right is of fundamental importance. Chapter seven explores security and some of the actions that the developer can take to both ensure access control and protect confidential data. Once the basics of Ajax are mastered, this may well be the most important chapter in the book. Chapter eight covers performance and what can be done to assist application speed and resource usage in practical use. Perhaps the most important measure for an Ajax application is the perceived speed and responsiveness that it delivers. The asynchronous processing is a huge factor in achieving these user perceptions.

Part four shows Ajax by example, with four chapters of example applications and a fifth chapter addressing building stand-alone applications using Ajax.

There is much to like about this book, but top of the fold for me is the clear and concise explanation of just what exactly Ajax is and why it has the power to make a difference in the web application arena. At a time when more people speak of Ajax than actually understand it, this book has the power to bring forth understanding.

This is a very dedicated book. It takes no time to teach the reader the individual technologies that compose Ajax, rather it concentrates on using those technologies. If you do not know JavaScript, or Cascading Style Sheets or do not understand the W3C's DOM model or asynchronous messaging then you would be better served at this time by learning the individual technologies and saving this book for after you've mastered them.

Other than the standard book page over at the Manning website, there is no dedicated book website. This is perhaps unusual, but 30 seconds on your search engine of choice should get you started. Failing that there is a good Ajax page available at Wikipedia.

This is a magnificent book. Not because it's well written and has good example code in it, although it is and it does. Rather, it is magnificent because of the high speed target that they have accurately hit and described in a clear and hype-free fashion; for this the authors are to be commended. If you want to create dynamic web applications, get this book."

You can purchase Ajax in Action from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

FrazzledDad writes "No, really. Please pick yourself up off the floor and stop laughing. Yes, there are good books on developing Windows software in a secure fashion. Keith Brown's The .NET Developer's Guide to Windows Security is right alongside Howard and LeBlanc's Writing Secure Code as examples of good Windows security works. Brown's book should be on any .NET Developer's bookshelf and will be of use to developers who work in other development platforms on Windows." Read on for the rest of the review. The .NET Developer's Guide to Windows Security author Keith Brown pages 408 publisher Addison-Wesley rating 9 reviewer Jim Holmes ISBN 0321228359 summary Terrific coverage of how to go about securely developing .NET software

I know the entire topic of Windows security may kick off a "slightly" enthusiastic debate among Slashdotters. I'd really prefer not to get wrapped up in a fray, so let me just say that a professional software developer needs to well understand the security issues in the environment and platform they're working on. This book's an important aid in that understanding. Great Fundamentals

Brown's book is broken into six parts, ranging from "The Big Picture", an overview of security on Windows, to "Access Control" and a wrap-up "Miscellaneous." Each part is made up of numerous "items," one topic which Brown elaborates on.

Brown covers a lot of very basic, important fundamentals such as "What is Authentication?", "What is a Luring Attack?", and "What is Kerberos?" He gives concise, clear overviews of each topic, then gets into the weeds where necessary.

For example, one of Brown's first emphatic points is that development on Windows platform shouldn't be done using an account with Administrator privileges. He covers the "why" in several early items, then spends 11 pages in Item 9 showing the approaches, tools, and issues involved in developing under a non-Admin account. This particular item needs to be stapled to far too many developers' foreheads because they don't understand, or care about, the ramifications of development as an Admin. Great Details

Brown also goes into great detail on many Items. His discussion of IPSEC is a good example. He spends Item 68 on the fundamentals of IPSEC such as key exchange and authentication, then goes on in Item 69 to discuss the details of implementing IPSEC via policies in a domain. He covers client and server configurations, then gives rationale for selecting various options. He also talks about why it's not the best solution, or even a complete solution, but does point out where IPSEC makes sense.

COM programming gets an entire section/part to itself, and Brown does a great job explaining the complex issues surrounding securing COM(+) communication. He discusses Authentication, Impersonation, and what calls you need to make in your Main method to properly invoke various COM security aspects.

Threat Modeling gets its own Item, but isn't covered in great depth. Brown lays out Microsoft's STRIDE system (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege) as a guideline for threat modeling. He also talks a bit about attack trees. Neither topic gets substantial treatment; however, Brown makes it clear he's only introducing these topics and points readers to several other resources such as Swiderski and Snyder's Threat Modeling. Great List of Cons and Problems

Part of good software engineering is understanding the ramifications of choices you make. Brown's very good about laying out the "Why" for his items, plus he's also clear where hard choices have to be made.

For example, in his discussion of IPSEC he asks "Where is IPSEC useful? When you don't have any better alternatives." He goes on to show how IPSEC can be used to help COM servers talk securely, or in .NET Remoting under the 1.1 Framework which stupidly doesn't provide secure communication channels.

Another example might be the erasability of a secret under .NET. Managed environments such as .NET and Java don't make it easy to ensure secrets (passwords, keys, etc.) can be erased out of the managed memory heap or at least overwritten immediately after their purpose is fulfilled. Not only can the object's memory be left unerased, but what about controlling whether it's written out to a swapfile? Brown points out these sorts of issues and tries to point out how to deal with them. What the Book Doesn't Cover

Brown's book isn't so much about specific coding techniques, although there are a fair number of those within. You won't find specifics on .NET's code access security, or issues around cross-site scripting. You'll need to look to Howard and LeBlanc's Writing Secure Code for code specifics.

Rather, the book is more about approaches to secure development on Windows. Brown's book also isn't about security and threat analysis, but again, he's forthright about that and points readers to other sources.

Bill Wagner, author of Effective C#, points out on his blog that Brown's book would be more usable if "titles [were] organized around the tasks I need to perform." I think that's a good criticism - a cookbook format would be a great improvement for a second edition. Summary

The book's very well written with a good index and a terrific Bibliography which serves as a great reading list for furthering one's knowledge of security on the Windows platform.

I've found the book very educational and useful. It's an important addition to my bookshelf and has already helped me with a couple of important topics. I think any professional, contentious developer working in the Windows environment would find this a vital addition to their bookshelf as well."

You can purchase The .NET Developer's Guide to Windows Security from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Joe Kauzlarich writes "There's an ever-growing number of fun niche books seeping onto the mathematics bookshelves, that, while not essential, are almost always guaranteed to leave the reader with a fuller taste of the subject at hand and an appetite to learn more. Mario Livio's The Equation That Couldn't Be Solved is a modest semi-classic of pop-math literature, focusing on the central concepts of group theory, the subject that turned mathematics on its head a century and a half ago and has ever since been one of the delights of studying higher mathematics." Read on for the rest of Joe's review. The Equation That Couldn't Be Solved: How Mathematical Genius Discovered the Language of Symmetry author Mario Livio pages 335 publisher Simon & Schuster rating 8/10 reviewer Joe Kauzlarich ISBN 0-7432-5820-7 summary Popular math/science

If you've studied group theory, you've probably heard it called 'the language of symmetry' or referred to by some such vague, colorful non-description, while your professor and textbook direct you to just memorize the handful of basic axioms, definitions, and theorems that reveal little to the unknowing eye in the way of having much to do with symmetry. Livio concentrates on the more colorful aspects of symmetry, spending little time with black and white textbook theory. For this reason, the book makes ideal extra-curricular entertainment for those enrolled in a first-semester course on abstract algebra.

It seems that Mario Livio's technique in writing books is to choose an ostensibly simple topic and explore it from a broad array of angles. In his second and most popular work, The Golden Ratio, he chose to write about the number Phi. The book reads like the front page of Slashdot, skipping quickly from topic to topic, though sticking to the general theme, insuring that the reader must never get bored. The treatment he once gave to Phi, he now gives to symmetry. Livio explores the concept of symmetry as it manifests itself in biology, art, physics and (especially, of course) mathematics. Then he broaches the most important topic of the book, group theory, and ventures upon the two stunning tales of its conception, as the book's two central figures independently discover that a certain equation cannot be solved by means of regular algebra (which, at the time, referred to the sort of formulaic manipulation done by today's undergrad algebra and calculus students; now, the word 'algebra,' in professional circles, includes group theory and much more).

At last, less-experienced readers will find a warm entry-way into one of the most fascinating and advanced branches of mathematics, one which has, through time, permeated most other branches. Experienced readers will revisit a familiar topic in its historical and mathematical-cultural context, as well as gain an 'intuitive' picture of group theoretical symmetry, an aspect often omitted from first semester advanced algebra courses. All readers can be comforted that mathematical notation is hardly anywhere to be found in the book. Experts need not fear wasting money to relearn what they already know and beginners can pick up the math through its brief mostly-English-language descriptions and should feel more comfortable diving into a course on the subject.

What is this Equation That Couldn't Be Solved? The equation in question is the quintic equation-- a polynomial of degree five (i.e. ax^5+bx^4+...+ex+f=0). You've probably studied the quadratic equation-- ax^2+bx+c=0-- as well as the quadratic formula, used to solve this equation-- x= (b(+/-)sqrt(b^2-4ac))/2a. The quintic equation cannot be solved by means of a formula and it took hundreds of years and two very young men to discover this. And as happens in so many famous instances throughout the history of science, the answer to a seemingly innocent little problem becomes the key to a revolution in thought.

A 22-year-old Norwegian named Niels Henrick Abel (1802-1829) and a 20-year-old Frenchman named Evariste Galois (1811-1832), discovered the impossibility of solving the quintic almost simultaneously in the 1820's. Both died within years of their discovery and both went unnoticed and uncelebrated until after their death. The tragedies that preceded their deaths-- Abel died essentially out of poverty; Galois, poor and already half-mad, in a pistol duel-- have served as a valuable lesson to the mathematical community ever since: spot genius early and foster it. Who knows what would have become of these men had they lived through the prime of their talents, just as the great Gauss and his contemporaries were developing the foundations for what would become Modern mathematics? It was Abel and, particularly, Galois, who defined the language of symmetry. Both saw The Equation in a light that had never been seen before.

Mario Livio is a historian as much as he is a scientist and the detail and color he gives to the lives of these tragic figures is unforgettable. Not only was his research thorough, but he even visited the regions he describes, and his results on the mysteries surrounding the death of Galois offer conclusiveness and definitiveness that seem hardly to have been matched in this particular line of research. Additionally, Livio digs up fresh mathematical anecdotes throughout the book, being careful not to repeat those stories or 'factoids' that are repeated ad nauseum across the genre.

Group theory has become an essential requisite of such diverse areas of scientific research as was unimaginable at the time of its inception. The fundamental particles of nature are arranged in groups, making the subject a cornerstone of particle physics and all physical 'theories of everything.' Group theory is the simplest sort of 'mathematical abstraction' (actually, it is a step past set theory) in that numbers and equations play no part in its basic definitions. Once you learn it well, then rings and fields follow. Then comes the fascinating study of topology, and then there is little that can stop you from learning anything you want mathematically (okay, that's a stretch). Cryptography is a modern applied field which requires a good working knowledge of group theory. I'm sure there are many other examples of applied group theory if you can't be convinced of the beauty of the subject in and for itself. Physics enthusiasts will enjoy the later chapter on group theory in modern particle physics, which is meant to show how integral the subject is to understanding and communicating the very laws of our universe.

While this is surely a bias on my part, I wasn't impressed with the amount of actual math described in the book. The very basics of group theory, as I mentioned, are elaborated upon-- the definition of a group, permutation groups, symmetry groups-- but Livio makes few attempts to make clear what group theorists study (mathematically-speaking) beyond these simple sorts of ideas. To his credit, he does explain Galois's proof quite clearly, considering the amount of time a student spends getting to it in textbooks. The book, as I've said, is foremost a look at symmetry, secondarily historical, and lastly, a math text. It is light reading, but-- take my word for it-- extremely entertaining and worth the few bucks. If you aren't much of a math geek, this book provides a great chance for you to get a glimpse at abstract algebra, which, IMHO, is one of the most fascinating branches of mathematics and, oddly, seems normally to be kept well-hidden from the eyes of non-math or non-physics majors."

You can purchase The Equation That Couldn't Be Solved from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Hemos writes "Most of the books sent to Slashdot for review have words like "Java", "hacks", or "802.11b" in the title, but occasionally an odd general book arrives after a publicist hits the wrong button on the keyboard. At first, I thought that John Hodgman's The Areas of My Expertise , was a mistake, but now I'm not sure. Because this is Slashdot, I'll spend the rest of the review wondering whether the Internet is really changing jokes, humor in general, and even all narrative form. But before that, I can tell you now that there's something sly, odd, and very funny about the book even though it is little more than a disconnected collection of lists and details. It's a coredump from a mind filled with 700 names of Hobos, the ways to use a ferret to rob a bank, the secret to winning every fight (use henchmen!), and the first draft of T.R. Roosevelt's famous command: speak softly and pierce their eyes with a golden hook." Read on for Peter Wayner's review. The Areas of My Expertise author John Hodgman pages 230 publisher rating 8 reviewer Peter Wayner ISBN summary

Let me help the curiosity of the general reader before I get to the meat of the review where I reveal enough Internet-releated theories to satisfy the nasty trolls who like to wonder why Slashdot is wasting valuable bits on silly topic. As John Hodgeman is fond of promising on his book's cover: "THE ANSWER IS PROVIDED".

The book is said to be a relatively complete collection of all of the important expertise in the mind of John Hodgeman, the author referred to on the cover as "A PROFESSIONAL WRITER." There's one section that contains the "700 Hobo names you requested." ("Irontrousers the Strong", "Fleastick" are 55 and 79). Another includes random crap about the 50 states. The sections are all very silly and the humor emerges from a form of metaphysical misdirection. I still chuckle when I think about the list of jokes that "have never produced laughter." The jokes really aren't funny, but there's something insane in their very deliberate and plodding failure.

The book can be sampled like a box of chocolates. I tried to read it through directly to see if any grand arc emerged, but my mind couldn't extract any great signal from the cultural noise. For all I know, he wrote each bit on an index card and then shuffled the cards before typesetting the book. The gags are all about the randomness of the wrong information cluttering his minds and, to a large extent, the texture of the words.

Long ago, an editor would have thrown this guy out on his ear for even suggesting that 230 some pages of chuckles would be worthy of getting people together for a book publication party. I don't think the editor or the publisher let those worries get in the way.

Which brings us to the answer I owe you about why this is a post- internet book. As the non-funny "unified theory of the web" in Small Pieces Loosely Joined pointed out, the web is made up by many small pieces of information arranges with hyperlinks that join them, loosely if you will. Well, that's this book. Random pieces of crap, given an additional shuffle to make it seem all the more random. It's all very loosely joined.

Long ago, professional writers like John Hodgman included narrative arcs and well-wrought plotlines with their books. Perhaps we don't need them any more. Maybe the Internet has changed our brain and made us happy to graze from the bar without the need of a sitdown meal. To put on my PROFESSIONAL POSTER hat, I think that the Internet has made us accustomed to getting our stuff in loosely joined pieces.

In fact it's worse than that. Most bloggers write complete paragraphs, but many parts of the book are just a collection of tiny bits that don't even qualify as full paragraphs. Many of the entries are just lists and many of the items in these lists aren't even complete sentences. This modern approach to writing is everywhere. Even the old dead-tree-based print media is producing magazines filled with so-called stories that are nothing more than lists of cool things to do, watch, or eat. The high-toned magazines may even have two or three sentences per list item--enough, I guess, to qualify as a paragraph, but most are nothing more than lists.

Some folks seem to feel that this fragmented, attention-deficit- whatever life is a good thing. Steven Johnson, for instance, argues in his book that the jumpy plots made of many short scenes are evidence of an expanding intellect. Modern TV seems almost unwatchable to me. But I also find old Starsky and Hutch episodes to be terribly plodding. Won't they just get to the point and catch the killers? But, back then, the journey was 9/10ths of the fun. The point wasn't really the point.

But maybe I'm just making too much of it. Plenty of comedy has always been filled with short pieces. Steve Martin's Cruel Shoes , for instance, was broken into a number of very short bits, although there really were a few threads woven throughout the book. Absurdist comedy like Monty Python's Flying Circus was just a collection of wacky riffs, but they did try to come up with clever and even more absurdist segueways to carry the viewer from scene to scene. It was not usual to have a bunch of guys walk into the frame of a sketch and carry one or more of the characters off and into the frame of another set.

At this point, I sort of feel that I need to add what PROFESSIONAL WRITERS call a "kicker", some sort of question or twist that connects us with the top of the piece and gives the reader a sense of closure. They're hard to find and even harder to craft. Ones that are even slightly funny or insightful can get you promoted. But, given the spirit of the book, I feel inclined to invoke the spirit of a hobo, slack a bit, and steal the ending from the book itself. (I can do this without spoiling the book for you!) As Hodgman writes when he comes to the end of the deck of joke cards, "That is all."

You can purchase The Areas of My Expertise from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

I've been reading a new book from O'Reilly which, despite my intense aversion to books of this type, outshines its class. Scott Berkun, has written The Art of Project Management. While my own review of it is tardy and still forthcoming, he & the fine folks at ORA have sent us an excerpt. Below is Chapter 13 - well worth reading, and getting the book. The Art of Project Management author Scott Berkun pages publisher O'Reilly rating reviewer Excerpt ISBN 0596007868 summary The Art of Project Management Chapter 13: How to make things happen

One myth of project management is that certain people have an innate ability to do it well, and others do not. Whenever this myth came up in conversation with other project managers, I always asked for an explanation of that ability—how to recognize it, categorize it, and, if possible, develop it in others. After discussion and debate, the only thing we usually identified—after considering many of the other topics and skills covered elsewhere in this book—is the ability to make things happen. Some people are able to apply their skills and talents in whatever combination necessary to move projects forward, and others cannot, even if they have the same or superior individual skills. The ability to make things happen is a combination of knowing how to be a catalyst or driver in a variety of different situations, and having the courage to do so.

This ability to drive is so important to some that it's used as a litmus test in hiring project managers. Even if PMs can't precisely define what the ability is without making at least some references to other skills, they do feel that they can sense or measure it in others. For example, an interviewer needs to ask herself the following question about the candidate: "If things were not going well on some important part of the project, would I feel confident sending this person into that room, into that discussion or debate, and believe he'd help find a way to make it better, whatever the problem was?" If after a round of interviews the answer is no, the candidate is sent home.(1) The belief is that if he isn't agile or flexible enough to adapt his skills and knowledge to the situations at hand, and find ways to drive things forward, then he won't survive, much less thrive, on a typical project. This chapter is about that ability and the skills and tactics involved.

Priorities make things happen

A large percentage of my time as a PM was spent making ordered lists. An ordered list is just a column of things, put in order of importance. I'm convinced that despite all of the knowledge and skills I was expected to have and use, in total, all I really did was make ordered lists. I collected things that had to be done—requirements, features, bugs, whatever—and put them in an order of importance to the project. I spent hours and days refining and revising these lists, integrating new ideas and information, debating and discussing them with others, always making sure they were rock solid. Then, once we had that list in place, I'd drive and lead the team as hard as possible to follow things in the defined order. Sometimes, these lists involved how my own time should be spent on a given day; other times, the lists involved what entire teams of people would do over weeks or months. But the process and the effect were the same.

I invested so much time in these lists because I knew that having clear priorities was the backbone of progress. Making things happen is dependent on having a clear sense of which things are more important than others and applying that sense to every single interaction that takes place on the team. These priorities have to be reflected in every email you send, question you ask, and meeting you hold. Every programmer and tester should invest energy in the things that will most likely bring about success. Someone has to be dedicated to both figuring out what those things are and driving the team to deliver on them.

What slows progress and wastes the most time on projects is confusion about what the goals are or which things should come before which other things. Many miscommunications and missteps happen because person A assumed one priority (make it faster), and person B assumed another (make it more stable). This is true for programmers, testers, marketers, and entire teams of people. If these conflicts can be avoided, more time can be spent actually progressing toward the project goals.

This isn't to say those debates about priorities shouldn't happen—they should. But they should happen early as part of whatever planning process you're using. If the same arguments keep resurfacing during development, it means people were not effectively convinced of the decision, or they have forgotten the logic and need to be reminded of why those decisions were made. Entertain debates, but start by asking if anything has changed since the plans were made to justify reconsidering the priorities. If nothing has changed (competitor behavior, new group mission, more/less resources, new major problems), stick to the decision.

If there is an ordered list posted up on the wall clarifying for everyone which things have been agreed to be more important than which other things, these arguments end quickly or never even start. Ordered lists provide everyone with a shared framework of logic to inherit their decisions from. If the goals are clear and understood, there is less need for interpretation and fewer chances for wasted effort.

So, if ever things on the team were not going well and people were having trouble focusing on the important things, I knew it was my fault: either I hadn't ordered things properly, hadn't effectively communicated those priorities, or had failed to execute and deliver on the order that we had. In such a case, working with prioritization and ordered lists meant everything.

Common ordered lists

By always working with a set order of priorities, adjustments and changes are easy to make. If, by some miracle, more time or resources are found in the schedule, it's clear what the next most important item is to work on. By the same token, if the schedule needs to be cut, everyone knows what the next least important item is and can stop working on it. This is incredibly important because it guarantees that no matter what happens, you will have done the most important work possible and can make quick adjustments without much effort or negative morale. Also, any prioritization mistakes you make will be relative: if work item 10 turns out to have been more important than work item 9, big deal. Because the whole list was in order, you won't have made a horrible mistake. And besides, by having such clear priorities and keeping the team focused on them, you may very well have bought the time needed to get work item 10 done after all.

For most projects, the three most important and most formal ordered lists are used to prioritize project goals, features, and work items (see Figure 13-1). The project goals are typically part of the vision document (see Chapter 4) or are derived from it. The lists of features and work items are the output of the design process (see Chapters 5, 6, and 7). Because each of these lists inherits priorities from the preceding list, by stepping up a level to reach a point of clarity and then reapplying those priorities back down to the level in question, any disputes can begin to be resolved. Although this may not always resolve debates, it will make sure that every decision was made in the context of what's truly important.

Figure 13-1. The three most important ordered lists, shown in order.

Other important things that might need ordered lists include bugs, customer suggestions, employee bonuses, and team budgets. They can all be managed in a similar way: put things in the order most likely to make the project or organization successful. No matter how complex the tools you use are (say, for bug tracking), never forget that all you're doing is ordering things. If the tools or processes you use don't help you put things in order and carry out that order, find a different tool or process. Bug triage, for example, where people get in a room and decide when a bug should be fixed (if at all), is really just a group process for making an ordered list of bugs. The bugs might be classified by group rather than on an individual bug-by-bug basis, but the purpose and effect are the same.

If you do use the three most common ordered lists, make sure that they always map to each other. Every engineering work item should map to a feature, and every feature should map to a goal. If a new work item is added, it must be matched against features and goals. This is a forcing function to prevent random features. If a VP or programmer wants to slip something extra in, she should be forced to justify it against what the project is trying to achieve: "That's a great feature, boss, but which goal will it help us satisfy? Either we should adjust the goals and deal with the consequences, or we shouldn't be investing energy here." If you teach the team that it's a rule to keep these three levels of decision making in sync, you will focus the team and prevent them from wasting time.

Priority 1 versus everything else

Typically, these ordered lists have one important line dividing them into two pieces. The top part is priority 1: things we must do and cannot possibly succeed without. The second part is everything else. Priorities 2 and 3 exist but are understood to be entirely different kinds of things from priority 1. It is very difficult to promote priority 2 items into priority 1.

This priority 1 line must be taken very seriously. You should fight hard to make that list as small and tight as possible (this applies to any goal lists in the vision document as well). An item in the priority 1 list means "We will die without this." It does not mean things that are nice to have or that we really want to have: it gives the tightest, leanest way to meet the project goals. For example, if we were building an automobile, the only priority 1 things would be the engine, tires, transmission, brakes, steering wheel, and pedals. Priority 2 items would be the doors, windshield, air conditioning, and radio because you can get around without those things. The core functionality of the automobile exists without them; you could ship it and still call it a car.

Putting this line in place was always very difficult; there was lots of arguing and debating about which things customers could live without or which things were more important than others. This was fine. We wanted all of the debating and arguing to take place early, but then move on. As painful as it would be, when we were finished, we'd have a list that had survived the opinions and perspectives of the team. We could then go forward and execute, having refutations and supporting arguments for the list we'd made. Having sharpened it through debate and argument, we were ready for 90% of the common questions or challenges people might have later on (i.e., why we were building brakes but not air conditioning) and could quickly dispatch them: we'd heard the arguments before, and we knew why they didn't hold up.

The challenge of prioritization is always more emotional/psychological than intellectual, despite what people say. Just like dieting to lose weight or budgeting to save money, eliminating things you want (but don't need) requires being disciplined, committed, and focused on the important goals. Saying "stability is important" is one thing, but stack ranking it against other important things is entirely different. Many managers chicken out of this process. They hedge, delay, and deny the tough choices, and the result is that they set their projects up to fail. No tough choices means no progress. In the abstract, the word important means nothing. So, ordered lists and the declaration of a high priority 1 bar forces leaders and the entire team to make tough decisions and think clearly.

Clarity is how you make things happen on projects. Everyone shows up to work each day with a strong sense of what he is doing, why he's doing it, and how it relates to what the others are doing. When the team asks questions about why one thing is more important than another, there are clear and logical reasons for it. Even when things change and priorities are adjusted, it's all within the same fundamental system of ordered lists and priority designations.

Priorities are power

Have you ever been in a tough argument that you thought would never end? Perhaps half the engineers felt strongly for A, and the other half felt strongly for B. But then the smart team leader walks in, asks some questions, divides the discussion in a new way, and quickly gets everyone to agree. It's happened to me many times. When I was younger, I chalked this up to brilliance: somehow that manager or lead programmer was just smarter than the rest of the people in the room, and saw things that we didn't. But as I paid more attention, and on occasion even asked them afterward how they did it, I realized it was about having rock-solid priorities. They had an ordered list in their heads and were able to get other people to frame the discussion around it. Good priorities are power. They eliminate secondary variables from the discussion, making it possible to focus and resolve issues.

If you have priorities in place, you can always ask questions in any discussion that reframe the argument around a more useful primary consideration. This refreshes everyone's sense of what success is, visibly dividing the universe into two piles: things that are important and things that are nice, but not important. Here are some sample questions:

• What problem are we trying to solve?

• If there are multiple problems, which one is most important?

• How does this problem relate to or impact our goals?

• What is the simplest way to fix this that will allow us to meet our goals?

• If nothing else, you will reset the conversation to focus on the project goals, which everyone can agree with. If a debate has gone on for hours, finding common ground is your best opportunity to moving the discussion toward a positive conclusion.

Be a prioritization machine

Whenever I talked with programmers or testers and heard about their issues or challenges, I realized that my primary value was in helping them focus. My aim was to eliminate secondary or tertiary things from their plates and to help them see a clear order of work. There are 1,000 ways to implement a particular web page design or database system to spec, but only a handful of them will really nail the objectives. Knowing this, I encouraged programmers to seek me out if they ever faced a decision where they were not sure which investment of time to make next.

But instead of micromanaging them ("Do this. No do that. No, do it this way. Are you done yet? How about now?"), I just made them understand that I was there to help them prioritize when they needed it. Because they didn't have the project-wide perspective I did, my value was in helping them to see, even if just for a moment, how what they were doing fit into the entire project. When they'd spent all day debugging a module or running unit tests, they were often relieved to get some higher-level clarity, reassurance, and confidence in what they were doing. It often took only a 30-second conversation to make sure we were all still on the same page.

Whenever new information came to the project, it was my job to interpret it (alone or through discussion with others), and form it into a prioritized list of things we had to care about and things we didn't. Often, I'd have to revise a previous list, adjusting it to respond to the new information. A VP might change her mind. A usability study might find new issues. A competitor might make an unexpected change. Those prioritizations were living, breathing things, and any changes to our direction or goals were reflected directly and immediately in them.

Because I maintained the priorities, I enabled the team to stay focused on the important things and actually make progress on them. Sometimes, I could reuse priorities defined by my superiors (vision documents, group mission statements); other times, I had to invent my own from scratch in response to ambiguity or unforeseen situations. But more than anything else, I was a prioritization machine. If there is ever a statue made in honor of good project managers, I suspect the inscription would say "Bring me your randomized, your righteously confused, your sarcastic and bitter masses of programmers yearning for clarity."

Things happen when you say no

One side effect of having priorities is how often you have to say no. It's one of the smallest words in the English language, yet many people have trouble saying it. The problem is that if you can't say no, you can't have priorities. The universe is a large place, but your priority 1 list should be very small. Therefore, most of what people in the world (or on your team) might think are great ideas will end up not matching the goals of the project. It doesn't mean their ideas are bad; it just means their ideas won't contribute to this particular project. So, a fundamental law of the PM universe is this: if you can't say no, you can't manage a project.(2)

Saying no starts at the top of an organization. The most senior people on a project will determine whether people can actually say no to requests. No matter what the priorities say, if the lead developer or manager continually says yes to things that don't jive with the priorities, others will follow. Programmers will work on pet features. PMs will add (hidden) requirements. Even if these individual choices are good, because the team is no longer following the same rules, nor working toward the same priorities, conflicts will occur. Sometimes, it will be disagreements between programmers, but more often, the result will be disjointed final designs. Stability, performance, and usability will all suffer. Without the focus of priorities, it's hard to get a team to coordinate on making the same thing. The best leaders and team managers know that they have to lead the way in saying no to things that are out of scope, setting the bar for the entire team.

When you do say no, and make it stick, the project gains momentum. Eliminating tasks from people's plates gives them more energy and motivation to focus and work hard on what they need to do. The number of meetings and random discussions will drop and efficiency will climb. Momentum will build around saying no: others will start doing it in their own spheres of influence. In fact, I've asked team members to do this. I'd say, "If you ever feel you're being asked to do something that doesn't jive with our priorities, say no. Or tell them that I said no, and they need to talk to me. And don't waste your time arguing with them if they complain—point them my way." I didn't want them wasting their time debating priorities with people because it was my expertise, not theirs. Even if they never faced these situations, I succeeded in expressing how serious the priorities were and how willing I was to work to defend them.

Master the many ways to say no

Sometimes, you will need to say no in direct response to a feature request. Other times, you'll need to interject yourself into a conversation or meeting, identify the conflict with priorities you've overheard, and effectively say no to whatever was being discussed. To prepare yourself for this, you need to know all of the different flavors that the word no comes in:

• No, this doesn't fit our priorities. If it is early in the project, you should make the argument for why the current priorities are good, but hear people out on why other priorities might make more sense. They might have good ideas or need clarity on the goals. But do force the discussion to be relative to the project priorities, and not the abstract value of a feature or bug fix request. If it is late in the project, you can tell them they missed the boat. Even if the priorities suck, they're not going to change on the basis of one feature idea. The later you are, the more severe the strategy failure needs to be to justify goal adjustments.

• No, only if we have time. If you keep your priorities lean, there will always be many very good ideas that didn't make the cut. Express this as a relative decision: the idea in question might be good, but not good enough relative to the other work and the project priorities. If the item is on the priority 2 list, convey that it's possible it will be done, but that no one should bet the farm assuming it will happen.

• No, only if you make <insert impossible thing here> happen. Sometimes, you can redirect a request back onto the person who made it. If your VP asks you to add support for a new feature, tell him you can do it only if he cuts one of his other current priority 1 requests. This shifts the point of contention away from you, and toward a tangible, though probably unattainable, situation. This can also be done for political or approval issues: "If you can convince Sally that this is a good idea, I'll consider it." However, this can backfire. (What if he does convince Sally? Or worse, realizes you're sending him on a wild goose chase?)

• No. Next release. Assuming you are working on a web site or software project that will have more updates, offer to reconsider the request for the next release. This should probably happen anyway for all priority 2 items. This is often called postponement or punting.

• No. Never. Ever. Really. Some requests are so fundamentally out of line with the long-term goals that the hammer has to come down. Cut the cord now and save yourself the time of answering the same request again later. Sometimes it's worth the effort to explain why (so that they'll be more informed next time). Example: "No, Fred. The web site search engine will never support the Esperanto language. Never. Ever."

Keeping it real

Some teams have a better sense of reality than others. You can find many stories of project teams that shipped their product months or years late, or came in millions of dollars over budget (see Robert Glass' Software Runaways, Prentice Hall, 1997). Little by little, teams believe in tiny lies or misrepresentations of the truth about what's going on, and slide into dangerous and unproductive places. As a rule, the further a team gets from reality, the harder it is to make good things happen. Team leaders must play the role of keeping their team honest (in the sense that the team can lose touch with reality, not that they deliberately lie), reminding people when they are making up answers, ignoring problematic situations, or focusing on the wrong priorities.

I remember a meeting I was in years ago with a small product team. They were building something that they wanted my team to use, and the presentation focused on the new features and technologies their product would have. Sitting near the back of the room, I felt increasingly uncomfortable with the presentation. None of the tough issues was being addressed or even mentioned. Then I realized the real problem: by not addressing the important issues, they were wasting everyone's time.

I looked around the room and realized part of the problem: I was the only lead from my organization in attendance. Normally, I'd have expected another PM or lead programmer to ask tough questions already. But with the faces in the room, I didn't know if anyone else was comfortable making waves when necessary. A thousand questions came to mind, and I quickly raised my hand, unleashing a series of simple questions, one after another. "What is your schedule? When can you get working code to us? Who are your other customers, and how will you prioritize their requests against ours? Why is it in our interest to make ourselves dependent on you and your team?" Their jaws dropped. They were entirely unprepared.

It was clear they had not considered these questions before. Worse, they did not expect to have to answer them for potential clients. I politely explained that they were not ready for this meeting. I apologized if my expectations were not made clear when the meeting was arranged (I thought they were). I told them that without those answers, this meeting was a waste of everyone's time, including theirs. I suggested we postpone the rest of the meeting until they had answers for these simple questions. They sheepishly agreed, and the meeting ended.

In PM parlance, what I did in this story was call bullshit. This is in reference to the card game Bullshit, where you win if you get rid of all the cards in your hand. In each turn of the game, a player states which cards he's playing as he places them face down into a pile. He is not obligated to tell the truth. So, if at any time another player thinks the first player is lying, she can "call bullshit" and force the first player to show his cards. If the accuser is right, the first player takes all of the cards in the pile (a major setback). However, if the accuser is wrong, she takes the pile.

Calling bullshit makes things happen. If people expect you will ask them tough questions, and not hesitate to push them hard until you get answers, they will prepare for them before they meet with you. They will not waste your or your team's time. Remember that all kinds of deception, including self-deception, work against projects. The sooner the truth comes to light, the sooner you can do something about it. Because most people avoid conflict and prefer to pretend things are OK (even when there is evidence they are not), someone has to push to get the truth out. The more you can keep the truth out in the open, the more your team can stay low to the ground, moving at high speed.

The challenge with questioning others is that it can run against the culture of an individual or organization. Some cultures see questioning as an insult or a lack of trust. They may see attempts to keep things honest as personal attacks, instead of as genuine inquiries into the truth. You may need to approach these situations more formally than I did in the story. Make a list of questions you expect people to answer, and provide it to them before meetings. Or, create a list of questions that anyone in the organization is free to ask anyone at any time (including VPs and PMs), and post it on the wall in a conference room. If you make it public knowledge from day one that bullshit will be called at any time, you can make it part of the culture without insulting anyone. However, leaders still have the burden of actually calling bullshit from time to time, demonstrating for the team that cutting quickly to the truth can be done.

Know the critical path

In project management terminology, the critical path is the shortest sequence of work that can complete the project. In critical path analysis, a diagram or flowchart is made of all work items, showing which items are dependent on which others. If done properly, this diagram shows where the bottlenecks will be. For example, if features A, B, and C can't be completed until D is done, then D is on the critical path for that part of the project. This is important because if D is delayed or done poorly, it will seriously impact the completion of work items A, B, and C. It's important then for a project manager to be able to plan and prioritize the critical path. Sometimes, a relatively unimportant component on its own can be the critical dependency that prevents true priority 1 work from being completed. Without doing critical path analysis, you might never recognize this until it is too late.(3)

From a higher-level perspective, there is a critical path to all situations. They don't need to be diagrammed or measured to the same level of detail, but the thought processes in assessing many PM situations are similar: look at the problem as a series of links, and see where the bottlenecks or critical points are. Which decisions or actions are dependent on which other decisions or actions? Then consider if enough attention is being paid to them, or if the real issue isn't the one currently being discussed. You dramatically accelerate a team by putting its attention directly on the elements, factors, and decisions that are central to progress.

Always have a sense for the critical path of:

• The project's engineering work (as described briefly earlier)

• The project's high-level decision-making process (who is slowing the team down?)

• The team's processes for building code or triaging bugs (are there needless forms, meetings, or approvals?)

• The production process of propping content to the Web or intranet

• Any meeting, situation, or process that impacts project goals

Making things happen effectively requires a strong sense of critical paths. Anytime you walk into a room, read an email, or get involved in a decision, you must think through what the critical paths are. Is this really the core issue? Will this discussion or line of thinking resolve it? Focus your energy (or the room's energy) on addressing those considerations first and evaluating what needs to be done to ensure those critical paths are made shorter, or resourced sufficiently, to prevent delays. If you can nail the critical path, less-critical issues will more easily fall into place.

For some organizations, the fastest way to improve the (non-engineering) critical path is to distribute authority across the team. Instead of requiring consensus, let individuals make decisions and use their own judgment as to when consensus is needed. Do the same thing for approvals, documentation, forms, or other possible bureaucratic overhead (see Chapter 10). Often the best way of improving critical paths in organizations is to remove processes and shift authority down and across a team, instead of creating new processes or hierarchies.

Be relentless

"The world responds to action, and not much else."

—Scott Adams

Many smart people can recognize when there is a problem, but few are willing to expend the energy necessary to find a solution, and then summon the courage to do it. There are always easier ways: give up, accept a partial solution, procrastinate until it goes away (fingers crossed), or blame others. The harder way is to take the problem head-on and resist giving in to conclusions that don't allow for satisfaction of the goals. Successful project managers simply do not give up easily. If something is important to the project, they will act aggressively—using any means necessary—to find an answer or solve the problem. This might mean reorganizing a dysfunctional team, getting a difficult room of people to agree on goals, finding answers to questions, or settling disagreements between people.

Sometimes, this means asking people to do things they don't like doing, or raising questions they don't want to answer. Without someone forcing those things to happen, the easier way out will tend to be chosen for you. Many projects consist of people with specialized roles who are unlikely to take responsibility for things that are beyond their limited scope (or that fall between the cracks of their role and someone else's). Perhaps more problematic is that most of us avoid conflict. It's often the PM who has to question people, challenge assumptions, and seek the truth, regardless of how uncomfortable it might make others (although the goal is to do this in a way that makes them as comfortable as possible). PMs have to be willing to do these things when necessary.

Many times situations that initially seem untenable or intractable crumble underneath the psychological effort of a tenacious project manager. A classic story about this attitude is the Apollo 13 mission. In his book Failure Is Not an Option (Berkeley Publishing, 2001), Gene Kranz describes the effort that went into fixing the life-support system on the damaged spacecraft. It was one of the hardest engineering challenges the team faced, and there were grave doubts among those with the most expertise that even a partial solution was possible. Kranz took the position that not only would they find a way, they would do so in the limited time allotted. He refused to accept any easy way out, and he pushed his team to explore alternatives, resolving their disputes and focusing their energy. All three versions of the story, the film Apollo 13, Kranz's book, and Lost Moon (Pocket, 1995) by Jim Lovell (the mission captain) and Jeffrey Kluger, provide fascinating accounts of one of the greatest project management and problem-solving stories in history.

Effective PMs simply consider more alternatives before giving up than other people do. They question the assumptions that were left unchallenged by others, because they came from either a VP people were afraid of or a source of superior expertise that no one felt the need to challenge. The question "How do you know what you know?" is the simplest way to clarify what is assumed and what is real, yet many people are afraid, or forget, to ask it. Being relentless means believing that 99% of the time there is a solution to the problem (including, in some cases, changing the definition of the problem), and that if it can't be found with the information at hand, then deeper and more probing questions need to be asked, no matter who has to be challenged. The success of the project has to come first.

In my years in the Windows division at Microsoft, I worked for Hillel Cooperman, perhaps the most passionate and dedicated manager I've ever had. I remember once coming into his office with a dilemma. My team was stuck on a complicated problem involving both engineering and political issues. We needed another organization to do important work for us, which they were unwilling to do. I had brainstormed with everyone involved, I had solicited opinions from other senior people, but I was still stuck. There didn't seem to be a reasonable solution, yet this was something critical to the project, and I knew giving in would be unacceptable. After explaining my situation, the conversation went something like this: "What haven't you tried yet?" I made the mistake of answering, "I've tried everything." He just laughed at me. "Everything? How could you possibly have tried everything? If you've tried everything, you'd have found a choice you feel comfortable with, which apparently you haven't yet." We found this funny because we both knew exactly where the conversation was going.

He then asked if I wanted some suggestions. Of course I said yes. We riffed for a few minutes, back and forth, and came up with a new list of things to consider. "Who haven't you called on the phone? Email isn't good for this kind of thing. And of all the people on the other side—those who disagree with you—who is most receptive to you? How hard have you sold them on what you want? Should I get involved and work from above you? Would that help? What about our VP? How hard have you pushed engineering to find a workaround? A little? A lot? As hard as possible? Did you offer to buy them drinks? Dinner? Did you talk to them one-on-one, or in a group? Keep going, keep going, keep going. You will find a way. I trust you, and I know you will solve this. Keep going."

He did two things for me: he reminded me that not only did I have alternatives, but also that it was still my authority to make the decision. As tired as I was, I left his office convinced there were more paths to explore and that it was my job to do so. My ownership of the issue, which he'd reconfirmed, helped motivate me to be relentless. The solution was lurking inside one of them, and I just had to find it. Like the dozens of other issues I was managing at the same time, I eventually found a solution (there was an engineering workaround), but only because I hunted for it: it was not going to come and find me.

Among other lessons, I learned from Hillel that diligence wins battles. If you make it clear that you are dead serious and will fight to the end about a particular issue, you force more possibilities to arise. People will question their assumptions if you hold on to yours long enough. You push people to consider things they haven't considered, and often that's where the answer lies. Even in disagreements or negotiations, if you know you're right, and keep pushing hard, people will often give in. Sometimes, they'll give in just to get you to leave them alone. Being pushy, provided you're not offensive, can be an effective technique all on its own.

Being relentless is fundamental to making things happen. There are so many different ways for projects to slide into failure that unless there is at least one emotional force behind the project—pushing it forward, seeking out alternatives, believing there is always a way out of every problem and trap—the project is unlikely to succeed. Good PMs are that force. They are compelled to keep moving forward, always on the lookout for something that can be improved in a faster or smarter way. They seek out chaos and convert it into clarity. As skeptical as project managers need to be, they are simultaneously optimistic that all problems can be solved if enough intensity and focus are applied. For reasons they themselves cannot fully explain, PMs continually hold a torch up against ambiguity and doubt, and refuse to quit until every possible alternative has been explored. They believe that good thinking wins, and that it takes work to find good thoughts.

Be savvy

But being relentless doesn't mean you have to knock on every door, chase people down the hallway, or stay at work until you pass out at your desk. Sheer quantity of effort can be noble and good, but always look for ways to work smart rather than just hard. Be relentless in spirit, but clever and savvy in action. Just because you refuse to give up doesn't mean you have to suffer through mindless, stupid, or frustrating activities (although sometimes they're unavoidable). Look for smart ways around a problem or faster ways to resolve them. Make effective use of the people around you instead of assuming you have to do everything yourself. But most importantly, be perceptive of what's going on around you, with individuals and with teams.

A fundamental mistake many PMs make is to forget to assess who they are working with and adjust their approach accordingly. Navy Seals and Army rangers are trained to carry out missions on many different kinds of terrain: deserts, swamps, jungles, tundra. Without this training, their effectiveness would be limited: they'd struggle to survive on unfamiliar terrain because their skills wouldn't work (imagine a solider in green and olive camouflage, trying to hide on a snow-covered field). The first lesson they learn is how to evaluate their environment and consider what tactics and strategies from their skill set will work for where they are. The same is true for PMs. Instead of geographic environments, PMs must pay attention to the different social, political, and organizational environments they are in, and use the right approaches for where they are.

Being savvy and environment-aware is most important in the following situations:

• Motivating and inspiring people

• Organizing teams and planning for action

• Settling arguments or breaking deadlocks

• Negotiating with other organizations or cultures

• Making arguments for resources

• Persuading anyone of anything

• Managing reports (personnel)

Here's the savvy PM's rough guide to evaluating an environment. These questions apply to an individual you might be working with or to the larger team or group:

• What communication styles are being used? Direct or indirect? Are people openly communicative, or are they reserved? Are there commonly accepted ways to make certain kinds of points? Are people generally effective in using email? Meetings? Are decisions made openly or behind closed doors? Match your approaches to the ones that will be effective with whomever you're talking to.

• How broad or narrow is the group's sense of humor? What topics are forbidden to laugh at or question? How are delicate/difficult/contentious subjects or decisions handled by others?

• Are arguments won based on data? Logical argument through debate? Adherence to the project goals? Who yells the loudest? Who has the brownest nose? Consider making arguments that use the style, format, or tone most palatable to your audience, whether it's a lone tester down the hall or a room full of executives.

• Who is effective at doing <insert thing you are trying to do here>, and what can I emulate or learn from them? Pay attention to what works. Who are the stars? Who gets the most respect? How are they thriving? Who is failing here? Why are they failing?

• In terms of actual behavior, what values are most important to this person or group? Intelligence? Courage? Speed? Clarity? Patience? Obedience? What behaviors are least valued or are deplored? Programmers and managers might have very different values. Know what the other guy values before you try to convince him of something.

• What is the organizational culture? Every university, corporation, or team has a different set of values built into the culture. If you don't think your organization has one, you've been there too long and can't see it anymore (or maybe you never saw it at all). Some organizations value loyalty and respect above intelligence and individuality. Others focus on work ethic and commitment.

Depending on the answers to these questions, a PM should make adjustments to how she does her work. Every time you enter another person's office, or another meeting, there should always be some adjustments made. Like a Marine, assess the environment and then judge the best route to get to the project goals. Avoid taking the hard road if there is a smarter way to get where you need to go.

Guerilla tactics

Being savvy means you are looking for, and willing to take, the smarter route. The following list contains tactics that I've used successfully or have been successfully used on me. While your mileage may vary with them, I'm sure this list will get you thinking of other savvy ways to accomplish what needs to be done to meet your goals. Some of these have risks, which I'll note, and must be applied carefully. Even if you choose never to use these yourself, by being aware of them, you will be savvier about what's going on around you.

• Go to the source. Don't dillydally with people's secondhand interpretations of what someone said, and don't depend on written reports or emails for complex information. Find the actual person and talk to him directly. You can't get new questions answered by reading reports or emails, and often people will tell you important things that were inappropriate for written communication. Going to the source is always more reliable and valuable than the alternatives, and it's worth the effort required. For example, if two programmers are arguing about what a third programmer said, get that third programmer in the room or on the phone. Always cut to the chase and push others to do the same.

• Switch communication modes. If communication isn't working, switch the mode. Instead of email, call them on the phone. Instead of a phone call, drop by their office. Everyone is more comfortable in some mediums than others. (Generally, face to face, in front of a whiteboard, trumps everything. Get people in a room with a whiteboard if the email thread on some issue gets out of control.) Don't let the limitations of a particular technology stop you. Sometimes, switching modes gets you a different response, even if your request is the same, because people are more receptive to one mode over another. For anything consequential, it's worth the money and time to get on a plane, or drive to their office, if it improves the communication dynamic between you and an important co-worker.

• Get people alone. When you talk to someone privately, her disposition toward you is different than when you talk to her in a large group. In a meeting, important people have to craft what they say to be appropriate for all of the ears in the room. Sometimes, you'll hear radically different things depending on who is in earshot. If you want a frank and honest opinion, or an in-depth intense conversation, you need to get people alone. Also, consider people of influence: if Jim trusts Beth's opinion, and you want to convince Jim, if you can convince Beth first, bring her along. Don't ambush anyone, but don't shy away from lining things up to make progress happen.

• Hunt people down. If something is urgent and you are not getting the response time you need, carve out time on your schedule to stake out the person's office or cubicle. I've done this many times. If he wasn't answering my phone calls or emails, he'd soon come back from a meeting and find me sitting by his door. He'd usually be caught so off guard that I'd have a negotiating advantage. Don't be afraid to go after people if you need something from them. Find them in the coffee room. Look for them in the café at lunchtime. Ask their secretary what meetings they are in and wait outside. Be polite, but hunt and get what you need. (However, please do not cross over into their personal lives. If you hunt information well, you shouldn't ever even need to cross this particular line.)

• Hide. If you are behind on work and need blocks of time to get caught up, become invisible. On occasion, I've staked out a conference room (in a neighboring building) and told only the people who really might need me where I was. I caught up on email, specs, employee evaluations, or anything important that wasn't getting done, without being interrupted. For smaller orgs, working from home or a coffee shop can have the same effect (wireless makes this easy these days). I always encouraged my reports to do this whenever they felt it necessary. Uninterrupted time can be hard for PMs to find, so if you can't find it, you have to make it.

• Get advice. Don't fly solo without a map unless you have to. In a given situation, consider who involved thinks most highly of you, or who may have useful advice for how you can get what you need. Make use of any expertise or experience you have access to through others. Pull them aside and ask them for it. This can be about a person, a decision, a plan, anything. "Hey Bob, I'd like your advice on this budget. Do you have a few minutes?" Or, "Jane, I'm trying to work with Sam on this issue. Any advice on the best way to convince him to cut this feature?" For many people, simply asking their advice will score you credibility points: it's an act of respect to ask for someone's opinion.

• Call in favors, beg, and bribe. Make use of the credibility or generosity you've developed a reputation for. If you need an engineer to do extra work for you, either because you missed something or a late requirement came in, ask her to do you a favor. Go outside the boundaries of the strict working relationship, and ask. Offer to buy her dinner ($20 is often well worth whatever the favor is), or tell her that you owe her one (and do hold yourself to this). The worst thing that can happen is that she'll say no. The more favors you've done for others, the more chips you'll have to bank on. Also, consider working three-way trades (e.g., in the game Settlers of Cattan) if you know of something she wants that you can get from someone else. It's not unethical to offer people things that will convince them to help with work that needs to be done.

• Play people off each other. This doesn't have to be evil—if you're very careful. If Sam gives you a work estimate of 10 days, which you think is bogus, go and ask Bob. If Bob says something less than 10 days, go back to Sam, with Bob. A conversation will immediately ensue about what the work estimate really should be. If you do this once, no engineer will ever give you bogus estimates again (you've called bullshit). However, depending on Sam's personality, this may cost you relationship points with him, so do it as tactfully as possible, and only when necessary. Good lead programmers should be calling estimate bluffs on their own, but if they don't, it's up to you.

• Buy people coffee and tasty things. This sounds stupid, but I've found that people I've argued with for days on end are somehow more receptive over a nice cup of coffee at a local coffee shop. Change the dynamic of the relationship: no matter how much you like or don't like the person, make the invitation and invest the 20 seconds of effort it requires. Even if he says "No, why can't we talk here?", you've lost nothing. Moving the conversation to a different location, perhaps one less formal, can help him open up to alternatives he wouldn't consider before. Think biologically: humans are in better moods after they've eaten a fine meal or when they are in more pleasant surroundings. I've seen PMs who keep doughnuts or cookies (as well as rum and scotch) in their office. Is that an act of goodwill? Yes...but there are psychological benefits to making sure the people you are working with are well fed and associate you with good things.

Summary

• Everything can be represented in an ordered list. Most of the work of project management is correctly prioritizing things and leading the team in carrying them out.

• The three most basic ordered lists are: project goals (vision), list of features, and list of work items. They should always be in sync with each other. Each work item contributes to a feature, and each feature contributes to a goal.

• There is a bright yellow line between priority 1 work and everything else.

• Things happen when you say no. If you can't say no, you effectively have no priorities.

• The PM has to keep the team honest and keep them close to reality.

• Knowing the critical path in engineering and team processes enables efficiency.

• You must be both relentless and savvy to make things happen.

I've been reading a new book from O'Reilly which, despite my intense aversion to books of this type, outshines its class. Scott Berkun, has written The Art of Project Management. While my own review of it is tardy and still forthcoming, he & the fine folks at ORA have sent us an excerpt. Below is Chapter 13 - well worth reading, and getting the book. The Art of Project Management author Scott Berkun pages publisher O'Reilly rating reviewer Excerpt ISBN 0596007868 summary The Art of Project Management Chapter 13: How to make things happen

One myth of project management is that certain people have an innate ability to do it well, and others do not. Whenever this myth came up in conversation with other project managers, I always asked for an explanation of that ability—how to recognize it, categorize it, and, if possible, develop it in others. After discussion and debate, the only thing we usually identified—after considering many of the other topics and skills covered elsewhere in this book—is the ability to make things happen. Some people are able to apply their skills and talents in whatever combination necessary to move projects forward, and others cannot, even if they have the same or superior individual skills. The ability to make things happen is a combination of knowing how to be a catalyst or driver in a variety of different situations, and having the courage to do so.

This ability to drive is so important to some that it's used as a litmus test in hiring project managers. Even if PMs can't precisely define what the ability is without making at least some references to other skills, they do feel that they can sense or measure it in others. For example, an interviewer needs to ask herself the following question about the candidate: "If things were not going well on some important part of the project, would I feel confident sending this person into that room, into that discussion or debate, and believe he'd help find a way to make it better, whatever the problem was?" If after a round of interviews the answer is no, the candidate is sent home.(1) The belief is that if he isn't agile or flexible enough to adapt his skills and knowledge to the situations at hand, and find ways to drive things forward, then he won't survive, much less thrive, on a typical project. This chapter is about that ability and the skills and tactics involved.

Priorities make things happen

A large percentage of my time as a PM was spent making ordered lists. An ordered list is just a column of things, put in order of importance. I'm convinced that despite all of the knowledge and skills I was expected to have and use, in total, all I really did was make ordered lists. I collected things that had to be done—requirements, features, bugs, whatever—and put them in an order of importance to the project. I spent hours and days refining and revising these lists, integrating new ideas and information, debating and discussing them with others, always making sure they were rock solid. Then, once we had that list in place, I'd drive and lead the team as hard as possible to follow things in the defined order. Sometimes, these lists involved how my own time should be spent on a given day; other times, the lists involved what entire teams of people would do over weeks or months. But the process and the effect were the same.

I invested so much time in these lists because I knew that having clear priorities was the backbone of progress. Making things happen is dependent on having a clear sense of which things are more important than others and applying that sense to every single interaction that takes place on the team. These priorities have to be reflected in every email you send, question you ask, and meeting you hold. Every programmer and tester should invest energy in the things that will most likely bring about success. Someone has to be dedicated to both figuring out what those things are and driving the team to deliver on them.

What slows progress and wastes the most time on projects is confusion about what the goals are or which things should come before which other things. Many miscommunications and missteps happen because person A assumed one priority (make it faster), and person B assumed another (make it more stable). This is true for programmers, testers, marketers, and entire teams of people. If these conflicts can be avoided, more time can be spent actually progressing toward the project goals.

This isn't to say those debates about priorities shouldn't happen—they should. But they should happen early as part of whatever planning process you're using. If the same arguments keep resurfacing during development, it means people were not effectively convinced of the decision, or they have forgotten the logic and need to be reminded of why those decisions were made. Entertain debates, but start by asking if anything has changed since the plans were made to justify reconsidering the priorities. If nothing has changed (competitor behavior, new group mission, more/less resources, new major problems), stick to the decision.

If there is an ordered list posted up on the wall clarifying for everyone which things have been agreed to be more important than which other things, these arguments end quickly or never even start. Ordered lists provide everyone with a shared framework of logic to inherit their decisions from. If the goals are clear and understood, there is less need for interpretation and fewer chances for wasted effort.

So, if ever things on the team were not going well and people were having trouble focusing on the important things, I knew it was my fault: either I hadn't ordered things properly, hadn't effectively communicated those priorities, or had failed to execute and deliver on the order that we had. In such a case, working with prioritization and ordered lists meant everything.

Common ordered lists

By always working with a set order of priorities, adjustments and changes are easy to make. If, by some miracle, more time or resources are found in the schedule, it's clear what the next most important item is to work on. By the same token, if the schedule needs to be cut, everyone knows what the next least important item is and can stop working on it. This is incredibly important because it guarantees that no matter what happens, you will have done the most important work possible and can make quick adjustments without much effort or negative morale. Also, any prioritization mistakes you make will be relative: if work item 10 turns out to have been more important than work item 9, big deal. Because the whole list was in order, you won't have made a horrible mistake. And besides, by having such clear priorities and keeping the team focused on them, you may very well have bought the time needed to get work item 10 done after all.

For most projects, the three most important and most formal ordered lists are used to prioritize project goals, features, and work items (see Figure 13-1). The project goals are typically part of the vision document (see Chapter 4) or are derived from it. The lists of features and work items are the output of the design process (see Chapters 5, 6, and 7). Because each of these lists inherits priorities from the preceding list, by stepping up a level to reach a point of clarity and then reapplying those priorities back down to the level in question, any disputes can begin to be resolved. Although this may not always resolve debates, it will make sure that every decision was made in the context of what's truly important.

Figure 13-1. The three most important ordered lists, shown in order.

Other important things that might need ordered lists include bugs, customer suggestions, employee bonuses, and team budgets. They can all be managed in a similar way: put things in the order most likely to make the project or organization successful. No matter how complex the tools you use are (say, for bug tracking), never forget that all you're doing is ordering things. If the tools or processes you use don't help you put things in order and carry out that order, find a different tool or process. Bug triage, for example, where people get in a room and decide when a bug should be fixed (if at all), is really just a group process for making an ordered list of bugs. The bugs might be classified by group rather than on an individual bug-by-bug basis, but the purpose and effect are the same.

If you do use the three most common ordered lists, make sure that they always map to each other. Every engineering work item should map to a feature, and every feature should map to a goal. If a new work item is added, it must be matched against features and goals. This is a forcing function to prevent random features. If a VP or programmer wants to slip something extra in, she should be forced to justify it against what the project is trying to achieve: "That's a great feature, boss, but which goal will it help us satisfy? Either we should adjust the goals and deal with the consequences, or we shouldn't be investing energy here." If you teach the team that it's a rule to keep these three levels of decision making in sync, you will focus the team and prevent them from wasting time.

Priority 1 versus everything else

Typically, these ordered lists have one important line dividing them into two pieces. The top part is priority 1: things we must do and cannot possibly succeed without. The second part is everything else. Priorities 2 and 3 exist but are understood to be entirely different kinds of things from priority 1. It is very difficult to promote priority 2 items into priority 1.

This priority 1 line must be taken very seriously. You should fight hard to make that list as small and tight as possible (this applies to any goal lists in the vision document as well). An item in the priority 1 list means "We will die without this." It does not mean things that are nice to have or that we really want to have: it gives the tightest, leanest way to meet the project goals. For example, if we were building an automobile, the only priority 1 things would be the engine, tires, transmission, brakes, steering wheel, and pedals. Priority 2 items would be the doors, windshield, air conditioning, and radio because you can get around without those things. The core functionality of the automobile exists without them; you could ship it and still call it a car.

Putting this line in place was always very difficult; there was lots of arguing and debating about which things customers could live without or which things were more important than others. This was fine. We wanted all of the debating and arguing to take place early, but then move on. As painful as it would be, when we were finished, we'd have a list that had survived the opinions and perspectives of the team. We could then go forward and execute, having refutations and supporting arguments for the list we'd made. Having sharpened it through debate and argument, we were ready for 90% of the common questions or challenges people might have later on (i.e., why we were building brakes but not air conditioning) and could quickly dispatch them: we'd heard the arguments before, and we knew why they didn't hold up.

The challenge of prioritization is always more emotional/psychological than intellectual, despite what people say. Just like dieting to lose weight or budgeting to save money, eliminating things you want (but don't need) requires being disciplined, committed, and focused on the important goals. Saying "stability is important" is one thing, but stack ranking it against other important things is entirely different. Many managers chicken out of this process. They hedge, delay, and deny the tough choices, and the result is that they set their projects up to fail. No tough choices means no progress. In the abstract, the word important means nothing. So, ordered lists and the declaration of a high priority 1 bar forces leaders and the entire team to make tough decisions and think clearly.

Clarity is how you make things happen on projects. Everyone shows up to work each day with a strong sense of what he is doing, why he's doing it, and how it relates to what the others are doing. When the team asks questions about why one thing is more important than another, there are clear and logical reasons for it. Even when things change and priorities are adjusted, it's all within the same fundamental system of ordered lists and priority designations.

Priorities are power

Have you ever been in a tough argument that you thought would never end? Perhaps half the engineers felt strongly for A, and the other half felt strongly for B. But then the smart team leader walks in, asks some questions, divides the discussion in a new way, and quickly gets everyone to agree. It's happened to me many times. When I was younger, I chalked this up to brilliance: somehow that manager or lead programmer was just smarter than the rest of the people in the room, and saw things that we didn't. But as I paid more attention, and on occasion even asked them afterward how they did it, I realized it was about having rock-solid priorities. They had an ordered list in their heads and were able to get other people to frame the discussion around it. Good priorities are power. They eliminate secondary variables from the discussion, making it possible to focus and resolve issues.

If you have priorities in place, you can always ask questions in any discussion that reframe the argument around a more useful primary consideration. This refreshes everyone's sense of what success is, visibly dividing the universe into two piles: things that are important and things that are nice, but not important. Here are some sample questions:

• What problem are we trying to solve?

• If there are multiple problems, which one is most important?

• How does this problem relate to or impact our goals?

• What is the simplest way to fix this that will allow us to meet our goals?

• If nothing else, you will reset the conversation to focus on the project goals, which everyone can agree with. If a debate has gone on for hours, finding common ground is your best opportunity to moving the discussion toward a positive conclusion.

Be a prioritization machine

Whenever I talked with programmers or testers and heard about their issues or challenges, I realized that my primary value was in helping them focus. My aim was to eliminate secondary or tertiary things from their plates and to help them see a clear order of work. There are 1,000 ways to implement a particular web page design or database system to spec, but only a handful of them will really nail the objectives. Knowing this, I encouraged programmers to seek me out if they ever faced a decision where they were not sure which investment of time to make next.

But instead of micromanaging them ("Do this. No do that. No, do it this way. Are you done yet? How about now?"), I just made them understand that I was there to help them prioritize when they needed it. Because they didn't have the project-wide perspective I did, my value was in helping them to see, even if just for a moment, how what they were doing fit into the entire project. When they'd spent all day debugging a module or running unit tests, they were often relieved to get some higher-level clarity, reassurance, and confidence in what they were doing. It often took only a 30-second conversation to make sure we were all still on the same page.

Whenever new information came to the project, it was my job to interpret it (alone or through discussion with others), and form it into a prioritized list of things we had to care about and things we didn't. Often, I'd have to revise a previous list, adjusting it to respond to the new information. A VP might change her mind. A usability study might find new issues. A competitor might make an unexpected change. Those prioritizations were living, breathing things, and any changes to our direction or goals were reflected directly and immediately in them.

Because I maintained the priorities, I enabled the team to stay focused on the important things and actually make progress on them. Sometimes, I could reuse priorities defined by my superiors (vision documents, group mission statements); other times, I had to invent my own from scratch in response to ambiguity or unforeseen situations. But more than anything else, I was a prioritization machine. If there is ever a statue made in honor of good project managers, I suspect the inscription would say "Bring me your randomized, your righteously confused, your sarcastic and bitter masses of programmers yearning for clarity."

Things happen when you say no

One side effect of having priorities is how often you have to say no. It's one of the smallest words in the English language, yet many people have trouble saying it. The problem is that if you can't say no, you can't have priorities. The universe is a large place, but your priority 1 list should be very small. Therefore, most of what people in the world (or on your team) might think are great ideas will end up not matching the goals of the project. It doesn't mean their ideas are bad; it just means their ideas won't contribute to this particular project. So, a fundamental law of the PM universe is this: if you can't say no, you can't manage a project.(2)

Saying no starts at the top of an organization. The most senior people on a project will determine whether people can actually say no to requests. No matter what the priorities say, if the lead developer or manager continually says yes to things that don't jive with the priorities, others will follow. Programmers will work on pet features. PMs will add (hidden) requirements. Even if these individual choices are good, because the team is no longer following the same rules, nor working toward the same priorities, conflicts will occur. Sometimes, it will be disagreements between programmers, but more often, the result will be disjointed final designs. Stability, performance, and usability will all suffer. Without the focus of priorities, it's hard to get a team to coordinate on making the same thing. The best leaders and team managers know that they have to lead the way in saying no to things that are out of scope, setting the bar for the entire team.

When you do say no, and make it stick, the project gains momentum. Eliminating tasks from people's plates gives them more energy and motivation to focus and work hard on what they need to do. The number of meetings and random discussions will drop and efficiency will climb. Momentum will build around saying no: others will start doing it in their own spheres of influence. In fact, I've asked team members to do this. I'd say, "If you ever feel you're being asked to do something that doesn't jive with our priorities, say no. Or tell them that I said no, and they need to talk to me. And don't waste your time arguing with them if they complain—point them my way." I didn't want them wasting their time debating priorities with people because it was my expertise, not theirs. Even if they never faced these situations, I succeeded in expressing how serious the priorities were and how willing I was to work to defend them.

Master the many ways to say no

Sometimes, you will need to say no in direct response to a feature request. Other times, you'll need to interject yourself into a conversation or meeting, identify the conflict with priorities you've overheard, and effectively say no to whatever was being discussed. To prepare yourself for this, you need to know all of the different flavors that the word no comes in:

• No, this doesn't fit our priorities. If it is early in the project, you should make the argument for why the current priorities are good, but hear people out on why other priorities might make more sense. They might have good ideas or need clarity on the goals. But do force the discussion to be relative to the project priorities, and not the abstract value of a feature or bug fix request. If it is late in the project, you can tell them they missed the boat. Even if the priorities suck, they're not going to change on the basis of one feature idea. The later you are, the more severe the strategy failure needs to be to justify goal adjustments.

• No, only if we have time. If you keep your priorities lean, there will always be many very good ideas that didn't make the cut. Express this as a relative decision: the idea in question might be good, but not good enough relative to the other work and the project priorities. If the item is on the priority 2 list, convey that it's possible it will be done, but that no one should bet the farm assuming it will happen.

• No, only if you make <insert impossible thing here> happen. Sometimes, you can redirect a request back onto the person who made it. If your VP asks you to add support for a new feature, tell him you can do it only if he cuts one of his other current priority 1 requests. This shifts the point of contention away from you, and toward a tangible, though probably unattainable, situation. This can also be done for political or approval issues: "If you can convince Sally that this is a good idea, I'll consider it." However, this can backfire. (What if he does convince Sally? Or worse, realizes you're sending him on a wild goose chase?)

• No. Next release. Assuming you are working on a web site or software project that will have more updates, offer to reconsider the request for the next release. This should probably happen anyway for all priority 2 items. This is often called postponement or punting.

• No. Never. Ever. Really. Some requests are so fundamentally out of line with the long-term goals that the hammer has to come down. Cut the cord now and save yourself the time of answering the same request again later. Sometimes it's worth the effort to explain why (so that they'll be more informed next time). Example: "No, Fred. The web site search engine will never support the Esperanto language. Never. Ever."

Keeping it real

Some teams have a better sense of reality than others. You can find many stories of project teams that shipped their product months or years late, or came in millions of dollars over budget (see Robert Glass' Software Runaways, Prentice Hall, 1997). Little by little, teams believe in tiny lies or misrepresentations of the truth about what's going on, and slide into dangerous and unproductive places. As a rule, the further a team gets from reality, the harder it is to make good things happen. Team leaders must play the role of keeping their team honest (in the sense that the team can lose touch with reality, not that they deliberately lie), reminding people when they are making up answers, ignoring problematic situations, or focusing on the wrong priorities.

I remember a meeting I was in years ago with a small product team. They were building something that they wanted my team to use, and the presentation focused on the new features and technologies their product would have. Sitting near the back of the room, I felt increasingly uncomfortable with the presentation. None of the tough issues was being addressed or even mentioned. Then I realized the real problem: by not addressing the important issues, they were wasting everyone's time.

I looked around the room and realized part of the problem: I was the only lead from my organization in attendance. Normally, I'd have expected another PM or lead programmer to ask tough questions already. But with the faces in the room, I didn't know if anyone else was comfortable making waves when necessary. A thousand questions came to mind, and I quickly raised my hand, unleashing a series of simple questions, one after another. "What is your schedule? When can you get working code to us? Who are your other customers, and how will you prioritize their requests against ours? Why is it in our interest to make ourselves dependent on you and your team?" Their jaws dropped. They were entirely unprepared.

It was clear they had not considered these questions before. Worse, they did not expect to have to answer them for potential clients. I politely explained that they were not ready for this meeting. I apologized if my expectations were not made clear when the meeting was arranged (I thought they were). I told them that without those answers, this meeting was a waste of everyone's time, including theirs. I suggested we postpone the rest of the meeting until they had answers for these simple questions. They sheepishly agreed, and the meeting ended.

In PM parlance, what I did in this story was call bullshit. This is in reference to the card game Bullshit, where you win if you get rid of all the cards in your hand. In each turn of the game, a player states which cards he's playing as he places them face down into a pile. He is not obligated to tell the truth. So, if at any time another player thinks the first player is lying, she can "call bullshit" and force the first player to show his cards. If the accuser is right, the first player takes all of the cards in the pile (a major setback). However, if the accuser is wrong, she takes the pile.

Calling bullshit makes things happen. If people expect you will ask them tough questions, and not hesitate to push them hard until you get answers, they will prepare for them before they meet with you. They will not waste your or your team's time. Remember that all kinds of deception, including self-deception, work against projects. The sooner the truth comes to light, the sooner you can do something about it. Because most people avoid conflict and prefer to pretend things are OK (even when there is evidence they are not), someone has to push to get the truth out. The more you can keep the truth out in the open, the more your team can stay low to the ground, moving at high speed.

The challenge with questioning others is that it can run against the culture of an individual or organization. Some cultures see questioning as an insult or a lack of trust. They may see attempts to keep things honest as personal attacks, instead of as genuine inquiries into the truth. You may need to approach these situations more formally than I did in the story. Make a list of questions you expect people to answer, and provide it to them before meetings. Or, create a list of questions that anyone in the organization is free to ask anyone at any time (including VPs and PMs), and post it on the wall in a conference room. If you make it public knowledge from day one that bullshit will be called at any time, you can make it part of the culture without insulting anyone. However, leaders still have the burden of actually calling bullshit from time to time, demonstrating for the team that cutting quickly to the truth can be done.

Know the critical path

In project management terminology, the critical path is the shortest sequence of work that can complete the project. In critical path analysis, a diagram or flowchart is made of all work items, showing which items are dependent on which others. If done properly, this diagram shows where the bottlenecks will be. For example, if features A, B, and C can't be completed until D is done, then D is on the critical path for that part of the project. This is important because if D is delayed or done poorly, it will seriously impact the completion of work items A, B, and C. It's important then for a project manager to be able to plan and prioritize the critical path. Sometimes, a relatively unimportant component on its own can be the critical dependency that prevents true priority 1 work from being completed. Without doing critical path analysis, you might never recognize this until it is too late.(3)

From a higher-level perspective, there is a critical path to all situations. They don't need to be diagrammed or measured to the same level of detail, but the thought processes in assessing many PM situations are similar: look at the problem as a series of links, and see where the bottlenecks or critical points are. Which decisions or actions are dependent on which other decisions or actions? Then consider if enough attention is being paid to them, or if the real issue isn't the one currently being discussed. You dramatically accelerate a team by putting its attention directly on the elements, factors, and decisions that are central to progress.

Always have a sense for the critical path of:

• The project's engineering work (as described briefly earlier)

• The project's high-level decision-making process (who is slowing the team down?)

• The team's processes for building code or triaging bugs (are there needless forms, meetings, or approvals?)

• The production process of propping content to the Web or intranet

• Any meeting, situation, or process that impacts project goals

Making things happen effectively requires a strong sense of critical paths. Anytime you walk into a room, read an email, or get involved in a decision, you must think through what the critical paths are. Is this really the core issue? Will this discussion or line of thinking resolve it? Focus your energy (or the room's energy) on addressing those considerations first and evaluating what needs to be done to ensure those critical paths are made shorter, or resourced sufficiently, to prevent delays. If you can nail the critical path, less-critical issues will more easily fall into place.

For some organizations, the fastest way to improve the (non-engineering) critical path is to distribute authority across the team. Instead of requiring consensus, let individuals make decisions and use their own judgment as to when consensus is needed. Do the same thing for approvals, documentation, forms, or other possible bureaucratic overhead (see Chapter 10). Often the best way of improving critical paths in organizations is to remove processes and shift authority down and across a team, instead of creating new processes or hierarchies.

Be relentless

"The world responds to action, and not much else."

—Scott Adams

Many smart people can recognize when there is a problem, but few are willing to expend the energy necessary to find a solution, and then summon the courage to do it. There are always easier ways: give up, accept a partial solution, procrastinate until it goes away (fingers crossed), or blame others. The harder way is to take the problem head-on and resist giving in to conclusions that don't allow for satisfaction of the goals. Successful project managers simply do not give up easily. If something is important to the project, they will act aggressively—using any means necessary—to find an answer or solve the problem. This might mean reorganizing a dysfunctional team, getting a difficult room of people to agree on goals, finding answers to questions, or settling disagreements between people.

Sometimes, this means asking people to do things they don't like doing, or raising questions they don't want to answer. Without someone forcing those things to happen, the easier way out will tend to be chosen for you. Many projects consist of people with specialized roles who are unlikely to take responsibility for things that are beyond their limited scope (or that fall between the cracks of their role and someone else's). Perhaps more problematic is that most of us avoid conflict. It's often the PM who has to question people, challenge assumptions, and seek the truth, regardless of how uncomfortable it might make others (although the goal is to do this in a way that makes them as comfortable as possible). PMs have to be willing to do these things when necessary.

Many times situations that initially seem untenable or intractable crumble underneath the psychological effort of a tenacious project manager. A classic story about this attitude is the Apollo 13 mission. In his book Failure Is Not an Option (Berkeley Publishing, 2001), Gene Kranz describes the effort that went into fixing the life-support system on the damaged spacecraft. It was one of the hardest engineering challenges the team faced, and there were grave doubts among those with the most expertise that even a partial solution was possible. Kranz took the position that not only would they find a way, they would do so in the limited time allotted. He refused to accept any easy way out, and he pushed his team to explore alternatives, resolving their disputes and focusing their energy. All three versions of the story, the film Apollo 13, Kranz's book, and Lost Moon (Pocket, 1995) by Jim Lovell (the mission captain) and Jeffrey Kluger, provide fascinating accounts of one of the greatest project management and problem-solving stories in history.

Effective PMs simply consider more alternatives before giving up than other people do. They question the assumptions that were left unchallenged by others, because they came from either a VP people were afraid of or a source of superior expertise that no one felt the need to challenge. The question "How do you know what you know?" is the simplest way to clarify what is assumed and what is real, yet many people are afraid, or forget, to ask it. Being relentless means believing that 99% of the time there is a solution to the problem (including, in some cases, changing the definition of the problem), and that if it can't be found with the information at hand, then deeper and more probing questions need to be asked, no matter who has to be challenged. The success of the project has to come first.

In my years in the Windows division at Microsoft, I worked for Hillel Cooperman, perhaps the most passionate and dedicated manager I've ever had. I remember once coming into his office with a dilemma. My team was stuck on a complicated problem involving both engineering and political issues. We needed another organization to do important work for us, which they were unwilling to do. I had brainstormed with everyone involved, I had solicited opinions from other senior people, but I was still stuck. There didn't seem to be a reasonable solution, yet this was something critical to the project, and I knew giving in would be unacceptable. After explaining my situation, the conversation went something like this: "What haven't you tried yet?" I made the mistake of answering, "I've tried everything." He just laughed at me. "Everything? How could you possibly have tried everything? If you've tried everything, you'd have found a choice you feel comfortable with, which apparently you haven't yet." We found this funny because we both knew exactly where the conversation was going.

He then asked if I wanted some suggestions. Of course I said yes. We riffed for a few minutes, back and forth, and came up with a new list of things to consider. "Who haven't you called on the phone? Email isn't good for this kind of thing. And of all the people on the other side—those who disagree with you—who is most receptive to you? How hard have you sold them on what you want? Should I get involved and work from above you? Would that help? What about our VP? How hard have you pushed engineering to find a workaround? A little? A lot? As hard as possible? Did you offer to buy them drinks? Dinner? Did you talk to them one-on-one, or in a group? Keep going, keep going, keep going. You will find a way. I trust you, and I know you will solve this. Keep going."

He did two things for me: he reminded me that not only did I have alternatives, but also that it was still my authority to make the decision. As tired as I was, I left his office convinced there were more paths to explore and that it was my job to do so. My ownership of the issue, which he'd reconfirmed, helped motivate me to be relentless. The solution was lurking inside one of them, and I just had to find it. Like the dozens of other issues I was managing at the same time, I eventually found a solution (there was an engineering workaround), but only because I hunted for it: it was not going to come and find me.

Among other lessons, I learned from Hillel that diligence wins battles. If you make it clear that you are dead serious and will fight to the end about a particular issue, you force more possibilities to arise. People will question their assumptions if you hold on to yours long enough. You push people to consider things they haven't considered, and often that's where the answer lies. Even in disagreements or negotiations, if you know you're right, and keep pushing hard, people will often give in. Sometimes, they'll give in just to get you to leave them alone. Being pushy, provided you're not offensive, can be an effective technique all on its own.

Being relentless is fundamental to making things happen. There are so many different ways for projects to slide into failure that unless there is at least one emotional force behind the project—pushing it forward, seeking out alternatives, believing there is always a way out of every problem and trap—the project is unlikely to succeed. Good PMs are that force. They are compelled to keep moving forward, always on the lookout for something that can be improved in a faster or smarter way. They seek out chaos and convert it into clarity. As skeptical as project managers need to be, they are simultaneously optimistic that all problems can be solved if enough intensity and focus are applied. For reasons they themselves cannot fully explain, PMs continually hold a torch up against ambiguity and doubt, and refuse to quit until every possible alternative has been explored. They believe that good thinking wins, and that it takes work to find good thoughts.

Be savvy

But being relentless doesn't mean you have to knock on every door, chase people down the hallway, or stay at work until you pass out at your desk. Sheer quantity of effort can be noble and good, but always look for ways to work smart rather than just hard. Be relentless in spirit, but clever and savvy in action. Just because you refuse to give up doesn't mean you have to suffer through mindless, stupid, or frustrating activities (although sometimes they're unavoidable). Look for smart ways around a problem or faster ways to resolve them. Make effective use of the people around you instead of assuming you have to do everything yourself. But most importantly, be perceptive of what's going on around you, with individuals and with teams.

A fundamental mistake many PMs make is to forget to assess who they are working with and adjust their approach accordingly. Navy Seals and Army rangers are trained to carry out missions on many different kinds of terrain: deserts, swamps, jungles, tundra. Without this training, their effectiveness would be limited: they'd struggle to survive on unfamiliar terrain because their skills wouldn't work (imagine a solider in green and olive camouflage, trying to hide on a snow-covered field). The first lesson they learn is how to evaluate their environment and consider what tactics and strategies from their skill set will work for where they are. The same is true for PMs. Instead of geographic environments, PMs must pay attention to the different social, political, and organizational environments they are in, and use the right approaches for where they are.

Being savvy and environment-aware is most important in the following situations:

• Motivating and inspiring people

• Organizing teams and planning for action

• Settling arguments or breaking deadlocks

• Negotiating with other organizations or cultures

• Making arguments for resources

• Persuading anyone of anything

• Managing reports (personnel)

Here's the savvy PM's rough guide to evaluating an environment. These questions apply to an individual you might be working with or to the larger team or group:

• What communication styles are being used? Direct or indirect? Are people openly communicative, or are they reserved? Are there commonly accepted ways to make certain kinds of points? Are people generally effective in using email? Meetings? Are decisions made openly or behind closed doors? Match your approaches to the ones that will be effective with whomever you're talking to.

• How broad or narrow is the group's sense of humor? What topics are forbidden to laugh at or question? How are delicate/difficult/contentious subjects or decisions handled by others?

• Are arguments won based on data? Logical argument through debate? Adherence to the project goals? Who yells the loudest? Who has the brownest nose? Consider making arguments that use the style, format, or tone most palatable to your audience, whether it's a lone tester down the hall or a room full of executives.

• Who is effective at doing <insert thing you are trying to do here>, and what can I emulate or learn from them? Pay attention to what works. Who are the stars? Who gets the most respect? How are they thriving? Who is failing here? Why are they failing?

• In terms of actual behavior, what values are most important to this person or group? Intelligence? Courage? Speed? Clarity? Patience? Obedience? What behaviors are least valued or are deplored? Programmers and managers might have very different values. Know what the other guy values before you try to convince him of something.

• What is the organizational culture? Every university, corporation, or team has a different set of values built into the culture. If you don't think your organization has one, you've been there too long and can't see it anymore (or maybe you never saw it at all). Some organizations value loyalty and respect above intelligence and individuality. Others focus on work ethic and commitment.

Depending on the answers to these questions, a PM should make adjustments to how she does her work. Every time you enter another person's office, or another meeting, there should always be some adjustments made. Like a Marine, assess the environment and then judge the best route to get to the project goals. Avoid taking the hard road if there is a smarter way to get where you need to go.

Guerilla tactics

Being savvy means you are looking for, and willing to take, the smarter route. The following list contains tactics that I've used successfully or have been successfully used on me. While your mileage may vary with them, I'm sure this list will get you thinking of other savvy ways to accomplish what needs to be done to meet your goals. Some of these have risks, which I'll note, and must be applied carefully. Even if you choose never to use these yourself, by being aware of them, you will be savvier about what's going on around you.

• Go to the source. Don't dillydally with people's secondhand interpretations of what someone said, and don't depend on written reports or emails for complex information. Find the actual person and talk to him directly. You can't get new questions answered by reading reports or emails, and often people will tell you important things that were inappropriate for written communication. Going to the source is always more reliable and valuable than the alternatives, and it's worth the effort required. For example, if two programmers are arguing about what a third programmer said, get that third programmer in the room or on the phone. Always cut to the chase and push others to do the same.

• Switch communication modes. If communication isn't working, switch the mode. Instead of email, call them on the phone. Instead of a phone call, drop by their office. Everyone is more comfortable in some mediums than others. (Generally, face to face, in front of a whiteboard, trumps everything. Get people in a room with a whiteboard if the email thread on some issue gets out of control.) Don't let the limitations of a particular technology stop you. Sometimes, switching modes gets you a different response, even if your request is the same, because people are more receptive to one mode over another. For anything consequential, it's worth the money and time to get on a plane, or drive to their office, if it improves the communication dynamic between you and an important co-worker.

• Get people alone. When you talk to someone privately, her disposition toward you is different than when you talk to her in a large group. In a meeting, important people have to craft what they say to be appropriate for all of the ears in the room. Sometimes, you'll hear radically different things depending on who is in earshot. If you want a frank and honest opinion, or an in-depth intense conversation, you need to get people alone. Also, consider people of influence: if Jim trusts Beth's opinion, and you want to convince Jim, if you can convince Beth first, bring her along. Don't ambush anyone, but don't shy away from lining things up to make progress happen.

• Hunt people down. If something is urgent and you are not getting the response time you need, carve out time on your schedule to stake out the person's office or cubicle. I've done this many times. If he wasn't answering my phone calls or emails, he'd soon come back from a meeting and find me sitting by his door. He'd usually be caught so off guard that I'd have a negotiating advantage. Don't be afraid to go after people if you need something from them. Find them in the coffee room. Look for them in the café at lunchtime. Ask their secretary what meetings they are in and wait outside. Be polite, but hunt and get what you need. (However, please do not cross over into their personal lives. If you hunt information well, you shouldn't ever even need to cross this particular line.)

• Hide. If you are behind on work and need blocks of time to get caught up, become invisible. On occasion, I've staked out a conference room (in a neighboring building) and told only the people who really might need me where I was. I caught up on email, specs, employee evaluations, or anything important that wasn't getting done, without being interrupted. For smaller orgs, working from home or a coffee shop can have the same effect (wireless makes this easy these days). I always encouraged my reports to do this whenever they felt it necessary. Uninterrupted time can be hard for PMs to find, so if you can't find it, you have to make it.

• Get advice. Don't fly solo without a map unless you have to. In a given situation, consider who involved thinks most highly of you, or who may have useful advice for how you can get what you need. Make use of any expertise or experience you have access to through others. Pull them aside and ask them for it. This can be about a person, a decision, a plan, anything. "Hey Bob, I'd like your advice on this budget. Do you have a few minutes?" Or, "Jane, I'm trying to work with Sam on this issue. Any advice on the best way to convince him to cut this feature?" For many people, simply asking their advice will score you credibility points: it's an act of respect to ask for someone's opinion.

• Call in favors, beg, and bribe. Make use of the credibility or generosity you've developed a reputation for. If you need an engineer to do extra work for you, either because you missed something or a late requirement came in, ask her to do you a favor. Go outside the boundaries of the strict working relationship, and ask. Offer to buy her dinner ($20 is often well worth whatever the favor is), or tell her that you owe her one (and do hold yourself to this). The worst thing that can happen is that she'll say no. The more favors you've done for others, the more chips you'll have to bank on. Also, consider working three-way trades (e.g., in the game Settlers of Cattan) if you know of something she wants that you can get from someone else. It's not unethical to offer people things that will convince them to help with work that needs to be done.

• Play people off each other. This doesn't have to be evil—if you're very careful. If Sam gives you a work estimate of 10 days, which you think is bogus, go and ask Bob. If Bob says something less than 10 days, go back to Sam, with Bob. A conversation will immediately ensue about what the work estimate really should be. If you do this once, no engineer will ever give you bogus estimates again (you've called bullshit). However, depending on Sam's personality, this may cost you relationship points with him, so do it as tactfully as possible, and only when necessary. Good lead programmers should be calling estimate bluffs on their own, but if they don't, it's up to you.

• Buy people coffee and tasty things. This sounds stupid, but I've found that people I've argued with for days on end are somehow more receptive over a nice cup of coffee at a local coffee shop. Change the dynamic of the relationship: no matter how much you like or don't like the person, make the invitation and invest the 20 seconds of effort it requires. Even if he says "No, why can't we talk here?", you've lost nothing. Moving the conversation to a different location, perhaps one less formal, can help him open up to alternatives he wouldn't consider before. Think biologically: humans are in better moods after they've eaten a fine meal or when they are in more pleasant surroundings. I've seen PMs who keep doughnuts or cookies (as well as rum and scotch) in their office. Is that an act of goodwill? Yes...but there are psychological benefits to making sure the people you are working with are well fed and associate you with good things.

Summary

• Everything can be represented in an ordered list. Most of the work of project management is correctly prioritizing things and leading the team in carrying them out.

• The three most basic ordered lists are: project goals (vision), list of features, and list of work items. They should always be in sync with each other. Each work item contributes to a feature, and each feature contributes to a goal.

• There is a bright yellow line between priority 1 work and everything else.

• Things happen when you say no. If you can't say no, you effectively have no priorities.

• The PM has to keep the team honest and keep them close to reality.

• Knowing the critical path in engineering and team processes enables efficiency.

• You must be both relentless and savvy to make things happen.

I've been reading a new book from O'Reilly which, despite my intense aversion to books of this type, outshines its class. Scott Berkun, has written The Art of Project Management. While my own review of it is tardy and still forthcoming, he & the fine folks at ORA have sent us an excerpt. Below is Chapter 13 - well worth reading, and getting the book. The Art of Project Management author Scott Berkun pages publisher O'Reilly rating reviewer Excerpt ISBN 0596007868 summary The Art of Project Management Chapter 13: How to make things happen

One myth of project management is that certain people have an innate ability to do it well, and others do not. Whenever this myth came up in conversation with other project managers, I always asked for an explanation of that ability—how to recognize it, categorize it, and, if possible, develop it in others. After discussion and debate, the only thing we usually identified—after considering many of the other topics and skills covered elsewhere in this book—is the ability to make things happen. Some people are able to apply their skills and talents in whatever combination necessary to move projects forward, and others cannot, even if they have the same or superior individual skills. The ability to make things happen is a combination of knowing how to be a catalyst or driver in a variety of different situations, and having the courage to do so.

This ability to drive is so important to some that it's used as a litmus test in hiring project managers. Even if PMs can't precisely define what the ability is without making at least some references to other skills, they do feel that they can sense or measure it in others. For example, an interviewer needs to ask herself the following question about the candidate: "If things were not going well on some important part of the project, would I feel confident sending this person into that room, into that discussion or debate, and believe he'd help find a way to make it better, whatever the problem was?" If after a round of interviews the answer is no, the candidate is sent home.(1) The belief is that if he isn't agile or flexible enough to adapt his skills and knowledge to the situations at hand, and find ways to drive things forward, then he won't survive, much less thrive, on a typical project. This chapter is about that ability and the skills and tactics involved.

Priorities make things happen

A large percentage of my time as a PM was spent making ordered lists. An ordered list is just a column of things, put in order of importance. I'm convinced that despite all of the knowledge and skills I was expected to have and use, in total, all I really did was make ordered lists. I collected things that had to be done—requirements, features, bugs, whatever—and put them in an order of importance to the project. I spent hours and days refining and revising these lists, integrating new ideas and information, debating and discussing them with others, always making sure they were rock solid. Then, once we had that list in place, I'd drive and lead the team as hard as possible to follow things in the defined order. Sometimes, these lists involved how my own time should be spent on a given day; other times, the lists involved what entire teams of people would do over weeks or months. But the process and the effect were the same.

I invested so much time in these lists because I knew that having clear priorities was the backbone of progress. Making things happen is dependent on having a clear sense of which things are more important than others and applying that sense to every single interaction that takes place on the team. These priorities have to be reflected in every email you send, question you ask, and meeting you hold. Every programmer and tester should invest energy in the things that will most likely bring about success. Someone has to be dedicated to both figuring out what those things are and driving the team to deliver on them.

What slows progress and wastes the most time on projects is confusion about what the goals are or which things should come before which other things. Many miscommunications and missteps happen because person A assumed one priority (make it faster), and person B assumed another (make it more stable). This is true for programmers, testers, marketers, and entire teams of people. If these conflicts can be avoided, more time can be spent actually progressing toward the project goals.

This isn't to say those debates about priorities shouldn't happen—they should. But they should happen early as part of whatever planning process you're using. If the same arguments keep resurfacing during development, it means people were not effectively convinced of the decision, or they have forgotten the logic and need to be reminded of why those decisions were made. Entertain debates, but start by asking if anything has changed since the plans were made to justify reconsidering the priorities. If nothing has changed (competitor behavior, new group mission, more/less resources, new major problems), stick to the decision.

If there is an ordered list posted up on the wall clarifying for everyone which things have been agreed to be more important than which other things, these arguments end quickly or never even start. Ordered lists provide everyone with a shared framework of logic to inherit their decisions from. If the goals are clear and understood, there is less need for interpretation and fewer chances for wasted effort.

So, if ever things on the team were not going well and people were having trouble focusing on the important things, I knew it was my fault: either I hadn't ordered things properly, hadn't effectively communicated those priorities, or had failed to execute and deliver on the order that we had. In such a case, working with prioritization and ordered lists meant everything.

Common ordered lists

By always working with a set order of priorities, adjustments and changes are easy to make. If, by some miracle, more time or resources are found in the schedule, it's clear what the next most important item is to work on. By the same token, if the schedule needs to be cut, everyone knows what the next least important item is and can stop working on it. This is incredibly important because it guarantees that no matter what happens, you will have done the most important work possible and can make quick adjustments without much effort or negative morale. Also, any prioritization mistakes you make will be relative: if work item 10 turns out to have been more important than work item 9, big deal. Because the whole list was in order, you won't have made a horrible mistake. And besides, by having such clear priorities and keeping the team focused on them, you may very well have bought the time needed to get work item 10 done after all.

For most projects, the three most important and most formal ordered lists are used to prioritize project goals, features, and work items (see Figure 13-1). The project goals are typically part of the vision document (see Chapter 4) or are derived from it. The lists of features and work items are the output of the design process (see Chapters 5, 6, and 7). Because each of these lists inherits priorities from the preceding list, by stepping up a level to reach a point of clarity and then reapplying those priorities back down to the level in question, any disputes can begin to be resolved. Although this may not always resolve debates, it will make sure that every decision was made in the context of what's truly important.

Figure 13-1. The three most important ordered lists, shown in order.

Other important things that might need ordered lists include bugs, customer suggestions, employee bonuses, and team budgets. They can all be managed in a similar way: put things in the order most likely to make the project or organization successful. No matter how complex the tools you use are (say, for bug tracking), never forget that all you're doing is ordering things. If the tools or processes you use don't help you put things in order and carry out that order, find a different tool or process. Bug triage, for example, where people get in a room and decide when a bug should be fixed (if at all), is really just a group process for making an ordered list of bugs. The bugs might be classified by group rather than on an individual bug-by-bug basis, but the purpose and effect are the same.

If you do use the three most common ordered lists, make sure that they always map to each other. Every engineering work item should map to a feature, and every feature should map to a goal. If a new work item is added, it must be matched against features and goals. This is a forcing function to prevent random features. If a VP or programmer wants to slip something extra in, she should be forced to justify it against what the project is trying to achieve: "That's a great feature, boss, but which goal will it help us satisfy? Either we should adjust the goals and deal with the consequences, or we shouldn't be investing energy here." If you teach the team that it's a rule to keep these three levels of decision making in sync, you will focus the team and prevent them from wasting time.

Priority 1 versus everything else

Typically, these ordered lists have one important line dividing them into two pieces. The top part is priority 1: things we must do and cannot possibly succeed without. The second part is everything else. Priorities 2 and 3 exist but are understood to be entirely different kinds of things from priority 1. It is very difficult to promote priority 2 items into priority 1.

This priority 1 line must be taken very seriously. You should fight hard to make that list as small and tight as possible (this applies to any goal lists in the vision document as well). An item in the priority 1 list means "We will die without this." It does not mean things that are nice to have or that we really want to have: it gives the tightest, leanest way to meet the project goals. For example, if we were building an automobile, the only priority 1 things would be the engine, tires, transmission, brakes, steering wheel, and pedals. Priority 2 items would be the doors, windshield, air conditioning, and radio because you can get around without those things. The core functionality of the automobile exists without them; you could ship it and still call it a car.

Putting this line in place was always very difficult; there was lots of arguing and debating about which things customers could live without or which things were more important than others. This was fine. We wanted all of the debating and arguing to take place early, but then move on. As painful as it would be, when we were finished, we'd have a list that had survived the opinions and perspectives of the team. We could then go forward and execute, having refutations and supporting arguments for the list we'd made. Having sharpened it through debate and argument, we were ready for 90% of the common questions or challenges people might have later on (i.e., why we were building brakes but not air conditioning) and could quickly dispatch them: we'd heard the arguments before, and we knew why they didn't hold up.

The challenge of prioritization is always more emotional/psychological than intellectual, despite what people say. Just like dieting to lose weight or budgeting to save money, eliminating things you want (but don't need) requires being disciplined, committed, and focused on the important goals. Saying "stability is important" is one thing, but stack ranking it against other important things is entirely different. Many managers chicken out of this process. They hedge, delay, and deny the tough choices, and the result is that they set their projects up to fail. No tough choices means no progress. In the abstract, the word important means nothing. So, ordered lists and the declaration of a high priority 1 bar forces leaders and the entire team to make tough decisions and think clearly.

Clarity is how you make things happen on projects. Everyone shows up to work each day with a strong sense of what he is doing, why he's doing it, and how it relates to what the others are doing. When the team asks questions about why one thing is more important than another, there are clear and logical reasons for it. Even when things change and priorities are adjusted, it's all within the same fundamental system of ordered lists and priority designations.

Priorities are power

Have you ever been in a tough argument that you thought would never end? Perhaps half the engineers felt strongly for A, and the other half felt strongly for B. But then the smart team leader walks in, asks some questions, divides the discussion in a new way, and quickly gets everyone to agree. It's happened to me many times. When I was younger, I chalked this up to brilliance: somehow that manager or lead programmer was just smarter than the rest of the people in the room, and saw things that we didn't. But as I paid more attention, and on occasion even asked them afterward how they did it, I realized it was about having rock-solid priorities. They had an ordered list in their heads and were able to get other people to frame the discussion around it. Good priorities are power. They eliminate secondary variables from the discussion, making it possible to focus and resolve issues.

If you have priorities in place, you can always ask questions in any discussion that reframe the argument around a more useful primary consideration. This refreshes everyone's sense of what success is, visibly dividing the universe into two piles: things that are important and things that are nice, but not important. Here are some sample questions:

• What problem are we trying to solve?

• If there are multiple problems, which one is most important?

• How does this problem relate to or impact our goals?

• What is the simplest way to fix this that will allow us to meet our goals?

• If nothing else, you will reset the conversation to focus on the project goals, which everyone can agree with. If a debate has gone on for hours, finding common ground is your best opportunity to moving the discussion toward a positive conclusion.

Be a prioritization machine

Whenever I talked with programmers or testers and heard about their issues or challenges, I realized that my primary value was in helping them focus. My aim was to eliminate secondary or tertiary things from their plates and to help them see a clear order of work. There are 1,000 ways to implement a particular web page design or database system to spec, but only a handful of them will really nail the objectives. Knowing this, I encouraged programmers to seek me out if they ever faced a decision where they were not sure which investment of time to make next.

But instead of micromanaging them ("Do this. No do that. No, do it this way. Are you done yet? How about now?"), I just made them understand that I was there to help them prioritize when they needed it. Because they didn't have the project-wide perspective I did, my value was in helping them to see, even if just for a moment, how what they were doing fit into the entire project. When they'd spent all day debugging a module or running unit tests, they were often relieved to get some higher-level clarity, reassurance, and confidence in what they were doing. It often took only a 30-second conversation to make sure we were all still on the same page.

Whenever new information came to the project, it was my job to interpret it (alone or through discussion with others), and form it into a prioritized list of things we had to care about and things we didn't. Often, I'd have to revise a previous list, adjusting it to respond to the new information. A VP might change her mind. A usability study might find new issues. A competitor might make an unexpected change. Those prioritizations were living, breathing things, and any changes to our direction or goals were reflected directly and immediately in them.

Because I maintained the priorities, I enabled the team to stay focused on the important things and actually make progress on them. Sometimes, I could reuse priorities defined by my superiors (vision documents, group mission statements); other times, I had to invent my own from scratch in response to ambiguity or unforeseen situations. But more than anything else, I was a prioritization machine. If there is ever a statue made in honor of good project managers, I suspect the inscription would say "Bring me your randomized, your righteously confused, your sarcastic and bitter masses of programmers yearning for clarity."

Things happen when you say no

One side effect of having priorities is how often you have to say no. It's one of the smallest words in the English language, yet many people have trouble saying it. The problem is that if you can't say no, you can't have priorities. The universe is a large place, but your priority 1 list should be very small. Therefore, most of what people in the world (or on your team) might think are great ideas will end up not matching the goals of the project. It doesn't mean their ideas are bad; it just means their ideas won't contribute to this particular project. So, a fundamental law of the PM universe is this: if you can't say no, you can't manage a project.(2)

Saying no starts at the top of an organization. The most senior people on a project will determine whether people can actually say no to requests. No matter what the priorities say, if the lead developer or manager continually says yes to things that don't jive with the priorities, others will follow. Programmers will work on pet features. PMs will add (hidden) requirements. Even if these individual choices are good, because the team is no longer following the same rules, nor working toward the same priorities, conflicts will occur. Sometimes, it will be disagreements between programmers, but more often, the result will be disjointed final designs. Stability, performance, and usability will all suffer. Without the focus of priorities, it's hard to get a team to coordinate on making the same thing. The best leaders and team managers know that they have to lead the way in saying no to things that are out of scope, setting the bar for the entire team.

When you do say no, and make it stick, the project gains momentum. Eliminating tasks from people's plates gives them more energy and motivation to focus and work hard on what they need to do. The number of meetings and random discussions will drop and efficiency will climb. Momentum will build around saying no: others will start doing it in their own spheres of influence. In fact, I've asked team members to do this. I'd say, "If you ever feel you're being asked to do something that doesn't jive with our priorities, say no. Or tell them that I said no, and they need to talk to me. And don't waste your time arguing with them if they complain—point them my way." I didn't want them wasting their time debating priorities with people because it was my expertise, not theirs. Even if they never faced these situations, I succeeded in expressing how serious the priorities were and how willing I was to work to defend them.

Master the many ways to say no

Sometimes, you will need to say no in direct response to a feature request. Other times, you'll need to interject yourself into a conversation or meeting, identify the conflict with priorities you've overheard, and effectively say no to whatever was being discussed. To prepare yourself for this, you need to know all of the different flavors that the word no comes in:

• No, this doesn't fit our priorities. If it is early in the project, you should make the argument for why the current priorities are good, but hear people out on why other priorities might make more sense. They might have good ideas or need clarity on the goals. But do force the discussion to be relative to the project priorities, and not the abstract value of a feature or bug fix request. If it is late in the project, you can tell them they missed the boat. Even if the priorities suck, they're not going to change on the basis of one feature idea. The later you are, the more severe the strategy failure needs to be to justify goal adjustments.

• No, only if we have time. If you keep your priorities lean, there will always be many very good ideas that didn't make the cut. Express this as a relative decision: the idea in question might be good, but not good enough relative to the other work and the project priorities. If the item is on the priority 2 list, convey that it's possible it will be done, but that no one should bet the farm assuming it will happen.

• No, only if you make <insert impossible thing here> happen. Sometimes, you can redirect a request back onto the person who made it. If your VP asks you to add support for a new feature, tell him you can do it only if he cuts one of his other current priority 1 requests. This shifts the point of contention away from you, and toward a tangible, though probably unattainable, situation. This can also be done for political or approval issues: "If you can convince Sally that this is a good idea, I'll consider it." However, this can backfire. (What if he does convince Sally? Or worse, realizes you're sending him on a wild goose chase?)

• No. Next release. Assuming you are working on a web site or software project that will have more updates, offer to reconsider the request for the next release. This should probably happen anyway for all priority 2 items. This is often called postponement or punting.

• No. Never. Ever. Really. Some requests are so fundamentally out of line with the long-term goals that the hammer has to come down. Cut the cord now and save yourself the time of answering the same request again later. Sometimes it's worth the effort to explain why (so that they'll be more informed next time). Example: "No, Fred. The web site search engine will never support the Esperanto language. Never. Ever."

Keeping it real

Some teams have a better sense of reality than others. You can find many stories of project teams that shipped their product months or years late, or came in millions of dollars over budget (see Robert Glass' Software Runaways, Prentice Hall, 1997). Little by little, teams believe in tiny lies or misrepresentations of the truth about what's going on, and slide into dangerous and unproductive places. As a rule, the further a team gets from reality, the harder it is to make good things happen. Team leaders must play the role of keeping their team honest (in the sense that the team can lose touch with reality, not that they deliberately lie), reminding people when they are making up answers, ignoring problematic situations, or focusing on the wrong priorities.

I remember a meeting I was in years ago with a small product team. They were building something that they wanted my team to use, and the presentation focused on the new features and technologies their product would have. Sitting near the back of the room, I felt increasingly uncomfortable with the presentation. None of the tough issues was being addressed or even mentioned. Then I realized the real problem: by not addressing the important issues, they were wasting everyone's time.

I looked around the room and realized part of the problem: I was the only lead from my organization in attendance. Normally, I'd have expected another PM or lead programmer to ask tough questions already. But with the faces in the room, I didn't know if anyone else was comfortable making waves when necessary. A thousand questions came to mind, and I quickly raised my hand, unleashing a series of simple questions, one after another. "What is your schedule? When can you get working code to us? Who are your other customers, and how will you prioritize their requests against ours? Why is it in our interest to make ourselves dependent on you and your team?" Their jaws dropped. They were entirely unprepared.

It was clear they had not considered these questions before. Worse, they did not expect to have to answer them for potential clients. I politely explained that they were not ready for this meeting. I apologized if my expectations were not made clear when the meeting was arranged (I thought they were). I told them that without those answers, this meeting was a waste of everyone's time, including theirs. I suggested we postpone the rest of the meeting until they had answers for these simple questions. They sheepishly agreed, and the meeting ended.

In PM parlance, what I did in this story was call bullshit. This is in reference to the card game Bullshit, where you win if you get rid of all the cards in your hand. In each turn of the game, a player states which cards he's playing as he places them face down into a pile. He is not obligated to tell the truth. So, if at any time another player thinks the first player is lying, she can "call bullshit" and force the first player to show his cards. If the accuser is right, the first player takes all of the cards in the pile (a major setback). However, if the accuser is wrong, she takes the pile.

Calling bullshit makes things happen. If people expect you will ask them tough questions, and not hesitate to push them hard until you get answers, they will prepare for them before they meet with you. They will not waste your or your team's time. Remember that all kinds of deception, including self-deception, work against projects. The sooner the truth comes to light, the sooner you can do something about it. Because most people avoid conflict and prefer to pretend things are OK (even when there is evidence they are not), someone has to push to get the truth out. The more you can keep the truth out in the open, the more your team can stay low to the ground, moving at high speed.

The challenge with questioning others is that it can run against the culture of an individual or organization. Some cultures see questioning as an insult or a lack of trust. They may see attempts to keep things honest as personal attacks, instead of as genuine inquiries into the truth. You may need to approach these situations more formally than I did in the story. Make a list of questions you expect people to answer, and provide it to them before meetings. Or, create a list of questions that anyone in the organization is free to ask anyone at any time (including VPs and PMs), and post it on the wall in a conference room. If you make it public knowledge from day one that bullshit will be called at any time, you can make it part of the culture without insulting anyone. However, leaders still have the burden of actually calling bullshit from time to time, demonstrating for the team that cutting quickly to the truth can be done.

Know the critical path

In project management terminology, the critical path is the shortest sequence of work that can complete the project. In critical path analysis, a diagram or flowchart is made of all work items, showing which items are dependent on which others. If done properly, this diagram shows where the bottlenecks will be. For example, if features A, B, and C can't be completed until D is done, then D is on the critical path for that part of the project. This is important because if D is delayed or done poorly, it will seriously impact the completion of work items A, B, and C. It's important then for a project manager to be able to plan and prioritize the critical path. Sometimes, a relatively unimportant component on its own can be the critical dependency that prevents true priority 1 work from being completed. Without doing critical path analysis, you might never recognize this until it is too late.(3)

From a higher-level perspective, there is a critical path to all situations. They don't need to be diagrammed or measured to the same level of detail, but the thought processes in assessing many PM situations are similar: look at the problem as a series of links, and see where the bottlenecks or critical points are. Which decisions or actions are dependent on which other decisions or actions? Then consider if enough attention is being paid to them, or if the real issue isn't the one currently being discussed. You dramatically accelerate a team by putting its attention directly on the elements, factors, and decisions that are central to progress.

Always have a sense for the critical path of:

• The project's engineering work (as described briefly earlier)

• The project's high-level decision-making process (who is slowing the team down?)

• The team's processes for building code or triaging bugs (are there needless forms, meetings, or approvals?)

• The production process of propping content to the Web or intranet

• Any meeting, situation, or process that impacts project goals

Making things happen effectively requires a strong sense of critical paths. Anytime you walk into a room, read an email, or get involved in a decision, you must think through what the critical paths are. Is this really the core issue? Will this discussion or line of thinking resolve it? Focus your energy (or the room's energy) on addressing those considerations first and evaluating what needs to be done to ensure those critical paths are made shorter, or resourced sufficiently, to prevent delays. If you can nail the critical path, less-critical issues will more easily fall into place.

For some organizations, the fastest way to improve the (non-engineering) critical path is to distribute authority across the team. Instead of requiring consensus, let individuals make decisions and use their own judgment as to when consensus is needed. Do the same thing for approvals, documentation, forms, or other possible bureaucratic overhead (see Chapter 10). Often the best way of improving critical paths in organizations is to remove processes and shift authority down and across a team, instead of creating new processes or hierarchies.

Be relentless

"The world responds to action, and not much else."

—Scott Adams

Many smart people can recognize when there is a problem, but few are willing to expend the energy necessary to find a solution, and then summon the courage to do it. There are always easier ways: give up, accept a partial solution, procrastinate until it goes away (fingers crossed), or blame others. The harder way is to take the problem head-on and resist giving in to conclusions that don't allow for satisfaction of the goals. Successful project managers simply do not give up easily. If something is important to the project, they will act aggressively—using any means necessary—to find an answer or solve the problem. This might mean reorganizing a dysfunctional team, getting a difficult room of people to agree on goals, finding answers to questions, or settling disagreements between people.

Sometimes, this means asking people to do things they don't like doing, or raising questions they don't want to answer. Without someone forcing those things to happen, the easier way out will tend to be chosen for you. Many projects consist of people with specialized roles who are unlikely to take responsibility for things that are beyond their limited scope (or that fall between the cracks of their role and someone else's). Perhaps more problematic is that most of us avoid conflict. It's often the PM who has to question people, challenge assumptions, and seek the truth, regardless of how uncomfortable it might make others (although the goal is to do this in a way that makes them as comfortable as possible). PMs have to be willing to do these things when necessary.

Many times situations that initially seem untenable or intractable crumble underneath the psychological effort of a tenacious project manager. A classic story about this attitude is the Apollo 13 mission. In his book Failure Is Not an Option (Berkeley Publishing, 2001), Gene Kranz describes the effort that went into fixing the life-support system on the damaged spacecraft. It was one of the hardest engineering challenges the team faced, and there were grave doubts among those with the most expertise that even a partial solution was possible. Kranz took the position that not only would they find a way, they would do so in the limited time allotted. He refused to accept any easy way out, and he pushed his team to explore alternatives, resolving their disputes and focusing their energy. All three versions of the story, the film Apollo 13, Kranz's book, and Lost Moon (Pocket, 1995) by Jim Lovell (the mission captain) and Jeffrey Kluger, provide fascinating accounts of one of the greatest project management and problem-solving stories in history.

Effective PMs simply consider more alternatives before giving up than other people do. They question the assumptions that were left unchallenged by others, because they came from either a VP people were afraid of or a source of superior expertise that no one felt the need to challenge. The question "How do you know what you know?" is the simplest way to clarify what is assumed and what is real, yet many people are afraid, or forget, to ask it. Being relentless means believing that 99% of the time there is a solution to the problem (including, in some cases, changing the definition of the problem), and that if it can't be found with the information at hand, then deeper and more probing questions need to be asked, no matter who has to be challenged. The success of the project has to come first.

In my years in the Windows division at Microsoft, I worked for Hillel Cooperman, perhaps the most passionate and dedicated manager I've ever had. I remember once coming into his office with a dilemma. My team was stuck on a complicated problem involving both engineering and political issues. We needed another organization to do important work for us, which they were unwilling to do. I had brainstormed with everyone involved, I had solicited opinions from other senior people, but I was still stuck. There didn't seem to be a reasonable solution, yet this was something critical to the project, and I knew giving in would be unacceptable. After explaining my situation, the conversation went something like this: "What haven't you tried yet?" I made the mistake of answering, "I've tried everything." He just laughed at me. "Everything? How could you possibly have tried everything? If you've tried everything, you'd have found a choice you feel comfortable with, which apparently you haven't yet." We found this funny because we both knew exactly where the conversation was going.

He then asked if I wanted some suggestions. Of course I said yes. We riffed for a few minutes, back and forth, and came up with a new list of things to consider. "Who haven't you called on the phone? Email isn't good for this kind of thing. And of all the people on the other side—those who disagree with you—who is most receptive to you? How hard have you sold them on what you want? Should I get involved and work from above you? Would that help? What about our VP? How hard have you pushed engineering to find a workaround? A little? A lot? As hard as possible? Did you offer to buy them drinks? Dinner? Did you talk to them one-on-one, or in a group? Keep going, keep going, keep going. You will find a way. I trust you, and I know you will solve this. Keep going."

He did two things for me: he reminded me that not only did I have alternatives, but also that it was still my authority to make the decision. As tired as I was, I left his office convinced there were more paths to explore and that it was my job to do so. My ownership of the issue, which he'd reconfirmed, helped motivate me to be relentless. The solution was lurking inside one of them, and I just had to find it. Like the dozens of other issues I was managing at the same time, I eventually found a solution (there was an engineering workaround), but only because I hunted for it: it was not going to come and find me.

Among other lessons, I learned from Hillel that diligence wins battles. If you make it clear that you are dead serious and will fight to the end about a particular issue, you force more possibilities to arise. People will question their assumptions if you hold on to yours long enough. You push people to consider things they haven't considered, and often that's where the answer lies. Even in disagreements or negotiations, if you know you're right, and keep pushing hard, people will often give in. Sometimes, they'll give in just to get you to leave them alone. Being pushy, provided you're not offensive, can be an effective technique all on its own.

Being relentless is fundamental to making things happen. There are so many different ways for projects to slide into failure that unless there is at least one emotional force behind the project—pushing it forward, seeking out alternatives, believing there is always a way out of every problem and trap—the project is unlikely to succeed. Good PMs are that force. They are compelled to keep moving forward, always on the lookout for something that can be improved in a faster or smarter way. They seek out chaos and convert it into clarity. As skeptical as project managers need to be, they are simultaneously optimistic that all problems can be solved if enough intensity and focus are applied. For reasons they themselves cannot fully explain, PMs continually hold a torch up against ambiguity and doubt, and refuse to quit until every possible alternative has been explored. They believe that good thinking wins, and that it takes work to find good thoughts.

Be savvy

But being relentless doesn't mean you have to knock on every door, chase people down the hallway, or stay at work until you pass out at your desk. Sheer quantity of effort can be noble and good, but always look for ways to work smart rather than just hard. Be relentless in spirit, but clever and savvy in action. Just because you refuse to give up doesn't mean you have to suffer through mindless, stupid, or frustrating activities (although sometimes they're unavoidable). Look for smart ways around a problem or faster ways to resolve them. Make effective use of the people around you instead of assuming you have to do everything yourself. But most importantly, be perceptive of what's going on around you, with individuals and with teams.

A fundamental mistake many PMs make is to forget to assess who they are working with and adjust their approach accordingly. Navy Seals and Army rangers are trained to carry out missions on many different kinds of terrain: deserts, swamps, jungles, tundra. Without this training, their effectiveness would be limited: they'd struggle to survive on unfamiliar terrain because their skills wouldn't work (imagine a solider in green and olive camouflage, trying to hide on a snow-covered field). The first lesson they learn is how to evaluate their environment and consider what tactics and strategies from their skill set will work for where they are. The same is true for PMs. Instead of geographic environments, PMs must pay attention to the different social, political, and organizational environments they are in, and use the right approaches for where they are.

Being savvy and environment-aware is most important in the following situations:

• Motivating and inspiring people

• Organizing teams and planning for action

• Settling arguments or breaking deadlocks

• Negotiating with other organizations or cultures

• Making arguments for resources

• Persuading anyone of anything

• Managing reports (personnel)

Here's the savvy PM's rough guide to evaluating an environment. These questions apply to an individual you might be working with or to the larger team or group:

• What communication styles are being used? Direct or indirect? Are people openly communicative, or are they reserved? Are there commonly accepted ways to make certain kinds of points? Are people generally effective in using email? Meetings? Are decisions made openly or behind closed doors? Match your approaches to the ones that will be effective with whomever you're talking to.

• How broad or narrow is the group's sense of humor? What topics are forbidden to laugh at or question? How are delicate/difficult/contentious subjects or decisions handled by others?

• Are arguments won based on data? Logical argument through debate? Adherence to the project goals? Who yells the loudest? Who has the brownest nose? Consider making arguments that use the style, format, or tone most palatable to your audience, whether it's a lone tester down the hall or a room full of executives.

• Who is effective at doing <insert thing you are trying to do here>, and what can I emulate or learn from them? Pay attention to what works. Who are the stars? Who gets the most respect? How are they thriving? Who is failing here? Why are they failing?

• In terms of actual behavior, what values are most important to this person or group? Intelligence? Courage? Speed? Clarity? Patience? Obedience? What behaviors are least valued or are deplored? Programmers and managers might have very different values. Know what the other guy values before you try to convince him of something.

• What is the organizational culture? Every university, corporation, or team has a different set of values built into the culture. If you don't think your organization has one, you've been there too long and can't see it anymore (or maybe you never saw it at all). Some organizations value loyalty and respect above intelligence and individuality. Others focus on work ethic and commitment.

Depending on the answers to these questions, a PM should make adjustments to how she does her work. Every time you enter another person's office, or another meeting, there should always be some adjustments made. Like a Marine, assess the environment and then judge the best route to get to the project goals. Avoid taking the hard road if there is a smarter way to get where you need to go.

Guerilla tactics

Being savvy means you are looking for, and willing to take, the smarter route. The following list contains tactics that I've used successfully or have been successfully used on me. While your mileage may vary with them, I'm sure this list will get you thinking of other savvy ways to accomplish what needs to be done to meet your goals. Some of these have risks, which I'll note, and must be applied carefully. Even if you choose never to use these yourself, by being aware of them, you will be savvier about what's going on around you.

• Go to the source. Don't dillydally with people's secondhand interpretations of what someone said, and don't depend on written reports or emails for complex information. Find the actual person and talk to him directly. You can't get new questions answered by reading reports or emails, and often people will tell you important things that were inappropriate for written communication. Going to the source is always more reliable and valuable than the alternatives, and it's worth the effort required. For example, if two programmers are arguing about what a third programmer said, get that third programmer in the room or on the phone. Always cut to the chase and push others to do the same.

• Switch communication modes. If communication isn't working, switch the mode. Instead of email, call them on the phone. Instead of a phone call, drop by their office. Everyone is more comfortable in some mediums than others. (Generally, face to face, in front of a whiteboard, trumps everything. Get people in a room with a whiteboard if the email thread on some issue gets out of control.) Don't let the limitations of a particular technology stop you. Sometimes, switching modes gets you a different response, even if your request is the same, because people are more receptive to one mode over another. For anything consequential, it's worth the money and time to get on a plane, or drive to their office, if it improves the communication dynamic between you and an important co-worker.

• Get people alone. When you talk to someone privately, her disposition toward you is different than when you talk to her in a large group. In a meeting, important people have to craft what they say to be appropriate for all of the ears in the room. Sometimes, you'll hear radically different things depending on who is in earshot. If you want a frank and honest opinion, or an in-depth intense conversation, you need to get people alone. Also, consider people of influence: if Jim trusts Beth's opinion, and you want to convince Jim, if you can convince Beth first, bring her along. Don't ambush anyone, but don't shy away from lining things up to make progress happen.

• Hunt people down. If something is urgent and you are not getting the response time you need, carve out time on your schedule to stake out the person's office or cubicle. I've done this many times. If he wasn't answering my phone calls or emails, he'd soon come back from a meeting and find me sitting by his door. He'd usually be caught so off guard that I'd have a negotiating advantage. Don't be afraid to go after people if you need something from them. Find them in the coffee room. Look for them in the café at lunchtime. Ask their secretary what meetings they are in and wait outside. Be polite, but hunt and get what you need. (However, please do not cross over into their personal lives. If you hunt information well, you shouldn't ever even need to cross this particular line.)

• Hide. If you are behind on work and need blocks of time to get caught up, become invisible. On occasion, I've staked out a conference room (in a neighboring building) and told only the people who really might need me where I was. I caught up on email, specs, employee evaluations, or anything important that wasn't getting done, without being interrupted. For smaller orgs, working from home or a coffee shop can have the same effect (wireless makes this easy these days). I always encouraged my reports to do this whenever they felt it necessary. Uninterrupted time can be hard for PMs to find, so if you can't find it, you have to make it.

• Get advice. Don't fly solo without a map unless you have to. In a given situation, consider who involved thinks most highly of you, or who may have useful advice for how you can get what you need. Make use of any expertise or experience you have access to through others. Pull them aside and ask them for it. This can be about a person, a decision, a plan, anything. "Hey Bob, I'd like your advice on this budget. Do you have a few minutes?" Or, "Jane, I'm trying to work with Sam on this issue. Any advice on the best way to convince him to cut this feature?" For many people, simply asking their advice will score you credibility points: it's an act of respect to ask for someone's opinion.

• Call in favors, beg, and bribe. Make use of the credibility or generosity you've developed a reputation for. If you need an engineer to do extra work for you, either because you missed something or a late requirement came in, ask her to do you a favor. Go outside the boundaries of the strict working relationship, and ask. Offer to buy her dinner ($20 is often well worth whatever the favor is), or tell her that you owe her one (and do hold yourself to this). The worst thing that can happen is that she'll say no. The more favors you've done for others, the more chips you'll have to bank on. Also, consider working three-way trades (e.g., in the game Settlers of Cattan) if you know of something she wants that you can get from someone else. It's not unethical to offer people things that will convince them to help with work that needs to be done.

• Play people off each other. This doesn't have to be evil—if you're very careful. If Sam gives you a work estimate of 10 days, which you think is bogus, go and ask Bob. If Bob says something less than 10 days, go back to Sam, with Bob. A conversation will immediately ensue about what the work estimate really should be. If you do this once, no engineer will ever give you bogus estimates again (you've called bullshit). However, depending on Sam's personality, this may cost you relationship points with him, so do it as tactfully as possible, and only when necessary. Good lead programmers should be calling estimate bluffs on their own, but if they don't, it's up to you.

• Buy people coffee and tasty things. This sounds stupid, but I've found that people I've argued with for days on end are somehow more receptive over a nice cup of coffee at a local coffee shop. Change the dynamic of the relationship: no matter how much you like or don't like the person, make the invitation and invest the 20 seconds of effort it requires. Even if he says "No, why can't we talk here?", you've lost nothing. Moving the conversation to a different location, perhaps one less formal, can help him open up to alternatives he wouldn't consider before. Think biologically: humans are in better moods after they've eaten a fine meal or when they are in more pleasant surroundings. I've seen PMs who keep doughnuts or cookies (as well as rum and scotch) in their office. Is that an act of goodwill? Yes...but there are psychological benefits to making sure the people you are working with are well fed and associate you with good things.

Summary

• Everything can be represented in an ordered list. Most of the work of project management is correctly prioritizing things and leading the team in carrying them out.

• The three most basic ordered lists are: project goals (vision), list of features, and list of work items. They should always be in sync with each other. Each work item contributes to a feature, and each feature contributes to a goal.

• There is a bright yellow line between priority 1 work and everything else.

• Things happen when you say no. If you can't say no, you effectively have no priorities.

• The PM has to keep the team honest and keep them close to reality.

• Knowing the critical path in engineering and team processes enables efficiency.

• You must be both relentless and savvy to make things happen.

Spencerian writes "The surge of Unix-derived operating systems such as Mac OS X, Linux, and the now-free Solaris is not slowing against the fortified but embattled breakwaters of the Microsoft operating system family. But new power users of other operating systems, including those just starting with Unix as well as the graphical interface of the operating system (such as the Mac OS Finder, or the navigators of KDE or Gnome), remain in need of a comprehensive primer for Unix that complements their previous knowledge. The fourth edition of Dave Taylor's "Teach Yourself Unix in 24 Hours" should remain on the top of the buy list for computer users in need of a strong Unix reference where they may find themselves managing or using the subtle variants of Unix flavors." Read the rest of Spencerians' review. Sams Teach Yourself Unix in 24 Hours, 4th Edition author Dave Taylor pages 518 publisher Sams Publishing rating 7.5 of 10 reviewer Kevin H Spencer ISBN 0-672-32814-3 summary The fourth edition of Dave Taylor's "Teach Yourself Unix in 24 Hours" should remain on the top of the buy list for computer users in need of a strong Unix reference where they may find themselves managing or using the subtle variants of Unix flavors.

The format of this Sams book, as with other books in this "Teach Yourself...In 24 Hours" series has not changed. The book content does favor Windows or Macintosh users when describing, comparisons and contrasts of Unix tasks to those popular operating systems. Unless the reader has been a fan of very little-used operating systems in their past and somehow managed to avoid Mac OS, Windows or Linux, absorption of what is needed for each chapter shouldn't be difficult.

Each chapter is technically noted as a one-hour lesson, although the author acknowledges that many may need more than one hour to absorb some material and should take as much time as they need to understand what they need to know. Chapters include the Unix basics such as using text editors such as vi, moving and copying files, viewing file contents and locating files in the operating system, and topics scale upward to advanced shell programming and even Perl programming. Generally, most readers need not read from beginning to end, chapter to chapter. Despite the lesson-like mode of the book, "Teach Yourself Unix" is a reference.

The "Teach Yourself" books are not advanced reference books, however, and "Teach Yourself Unix in 24 Hours" is no exception. As someone that's used more and more Unix commands in the background of Mac OS X to make things easier or to circumvent limitations or flaws of the Mac OS X Finder, the previous editions of "Teach Yourself Unix" were handy references when I needed a quick and certain process to accomplish a task. Sometimes it's too easy for graphical interface users to moan and while when the Windows Explorer or Mac OS X desktops stick and slows to a crawl when managing something as simple as copying a file, forgetting that there is another way. This book contains the basics to manage these tasks without being too basic of a reference.

The author's breadth of knowledge in many Unix-derived systems such as BSD, Solaris, and Linux continue to extend themselves well in the lessons. Each chapter contains explanations and examples to aid those that need more information. Most Slashdot readers might find this level of detail a bit plodding, but some newbies to Unix may need this since Unix is not inherently a graphical operating system that's easy to understand by sight, so things need to be literally spelled out. Peppered throughout the book are sidenotes that keep the reader apprised of exceptions or proper etiquette when handling, discussing or pronouncing Unix tasks and terminology.

There's a marginally useful amount of back matter on the book, consisting of two appendices, one on frequently-asked Unix questions, and another more useful appendix on managing the Apache web server from a command line. The back cover has a simple command-line reference that's not bad, however, being Unix, the amount of commands and versatility seem a bit limited, so the command-line reference lacks a bit of punch. Some chapters seem a bit archaic and probably need to be reconsidered in a future edition--very few of us may have a need to send mail from the command line in this age of Yahoo Mail and the sheer number of mail services available on computers in schools, businesses, homes, and even from cell phones for jotting off a quick note to a comrade for quick answers. Full-time conversing by mail in Unix isn't something I feel anyone but the most hardcore Unix user will relish--and those users aren't the audience of this book.

This book is designed for new Unix users, but intermediate users will find "Teach Yourself Unix in 24 Hours" a handy reference when having to workaround GUI pitfalls or failures. This book's previous versions have saved my bacon in reinforcing my previous experience and skills at the command line when the Mac OS Finder seizes, leaving no graphical way to complete a task. Unfortunately, given the volume of information I must remember in using both Mac OS X and Windows XP, I, for one, can't remember every nuance of Unix needed, particularly since it's not as easily remembered as icons or menus. Perhaps the author may find that a fifth edition will need information on the long-awaited Windows Vista in the event it contains Unix parts and pieces."

You can purchase Sams Teach Yourself Unix in 24 Hours from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

r3lody writes "Hardening Linux, by James Turnbull, stands out as an important text that clearly lays out how to make your Linux boxes as secure as possible. Mr. Turnbull has done a noteworthy job in delineating many potential vulnerabilities, and how to mitigate them. Each chapter covers a particular area in depth, with carefully worded and easy-to-follow examples. In the cases where you need to install some other piece of software to provide extra security, Turnbull gives you the step-by-step details, removing the chance of misinterpretation. As you finish each chapter, you will want to apply your newfound knowledge to the machines at your disposal." Read on for r3lody's review. Hardening Linux author James Turnbull pages 584 publisher Apress rating 9/10 reviewer Ray Lodato (rlodato AT yahoo DOT com) ISBN 1590594444 summary In-depth explanations with step-by-step techniques for securing Linux and common applications.

Naturally, the strongest building will collapse if built on a weak foundation, so Turnbull starts by considering what you need to harden a stand-alone Linux host. He discusses what applications to install and how to secure the boot loader (both LILO and GRUB are covered). The init sequences and scripts are covered next, as well as the login screen. Information on securing users and groups using PAM (Pluggable Authentication Modules) comes next, followed by package management and kernel patching. Finally, Turnbull finishes up with how to keep informed on security issues in the future. All of that is contained in chapter 1, and there are ten more to go! Each chapter ends with a list of resources in the form of mailing lists, web sites, books, etc., so you can fill in any blanks Turnbull may have left in.

Current security postures dictate that every network-connected device needs to be secured from the inside out. Turnbull apparently believes the same thing, and covers the Netfilter firewall framework built into the Linux kernel. Once again providing the careful step-by-step procedures, he demonstrates how to use iptables to manipulate Netfilter chains for maximum protection. There are a number of kernel parameters to Netfilter that can be modified using the sysctl command. James describes the more important ones (such as conf/all/accept_redirects, icmp_echo_ignore_broadcasts, and all under the /proc/sys/net/ipv4 pseudo-directory), and how to keep the changes in place across reboots. He also discusses how to log firewall rules, and keep the code updated using Patch-O-Matic.

As each subsequent chapter unfolds, Turnbull carefully explains how to tighten remote administration, files and file systems, mail, ftp, and DNS/BIND. He gives additional information on how to log important information securely and efficiently monitor the data collected. In addition, tools for testing the security of your hosts are described very clearly, from the inside out and the outside in, along with explanations of how to detect penetrations and recover from them.

Writing about securing a computer system can be written on a few different levels, from the general suggestions which apply to just about any program, to the specific which apply to just one. Turnbull picked commonly used programs and provide step-by-step procedures for locking them down. For example, if you are hardening a mail server, you will find descriptions of Sendmail and Postfix, but not of Qmail or Courier. While this might limit the appeal of the book to just those using the more common programs, it allows a depth that would be otherwise unavailable.

The only quibble I have is that his book does not go far enough. While the chosen applications are covered in great depth, some applications are missing. There is no coverage for a web server, such as Apache, or a database server, such as MySQL. I can only hope that a future edition of the book includes chapters on these and other categories of programs.

Hardening Linux by James Turnbull belongs on the shelf of anyone who installs and maintains Linux servers. The information is easy to follow, and will help you configure your systems very securely. The additional insights into why the configurations are important is extremely valuable in its own right."

You can purchase Hardening Linux from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Simon P. Chappell writes "Much as a certain large software company located in the North-West of the United States of America might wish otherwise, there are many different operating systems and platforms in use in the world today. Software these days needs to able to operate in a disparate environment, either by communicating with these other platforms or by running on them or, increasingly, doing both. The Information Systems industry is making good progress with the communication half of the problem (even if a lot of it seems to involve large amounts of XML), but it is still struggling with the issues inherent with writing portable code. Brian Hook's contribution to all of this is Write Portable Code , which according to it's subtitle is an introduction to developing software for multiple platforms." Read on for the rest of Simon's review. Write Portable Code author Brian Hook pages 248 (14 page index) publisher No Starch Press rating 8/10 reviewer Simon P. Chappell ISBN 1593270569 summary I recommend this book to anyone working with portable code.

This is a book for computer programmers who write software designed to run on multiple platforms. It's also for programmers who suspect that their software may need to run on different platforms. This brings the book onto the radar for free and open source software authors, as they seek to create software that does not trap their end users into using specific operating systems. The Structure

There is a good progression shown in the eighteen chapters of the book. The first couple of chapters introduce the reader to portability concepts and then to some of the specific portability features of ANSI C and C++ that are used throughout the rest of the book.

The middle chapters of the book, cover individual portability topics. Some of these topics are the obvious ones, like Floating Point numbers, Networking, Operating System, File System and Dynamic Libraries. Other topics are less intuitively associated with portability, but when you read the chapter, it's inclusion is both obvious and necessary. These subjects include Source Code Management, Compilers, Scalability and Data. There is more to portability than many of us might suspect.

The last two chapters look at some alternative ways of getting portability. Scripting languages are discussed and the pros and cons of each ones portability is weighed. Lastly the use of cross-platform libraries and toolkits is addressed. Quite apropos given that the book's author is also the author of a cross platform library.

As an example of the thoughtful approach taken in this book, lets' take a look at the chapter on scripting languages. It's about the shortest chapter in the book, but representative of the approach that Mr. Hook brings to his work. This chapter takes a very honest look at the portability and cross-platform aspects of using scripting languages. There are advantages and disadvantages to the use of scripting languages. The advantages include everything that is a disadvantage of low-level languages like C/C++. Scripting languages do not require you to worry about about memory allocation, bindings, System API calls or any of the other bugbears of a low-level language programmer's life. The disadvantages of scripting languages naturally include performance, given their interpreted natures, a general lack of tools, such as development environments or IDEs and their tendency to sit high above the operating system with a corresponding detachment from low-level facilities and services of that same operating system. Mr. Hook's choice of scripting languages to consider was interesting. I expected Ruby and Python; both popular and capable in their own right. The inclusion of JavaScript/ECMAScript was also not too unexpected, now that standalone versions are bubbling up and becoming available. The real surprise, albeit a pleasant one, was the inclusion of Lua; a scripting language designed for platform portability and which seems to have managed to fully mature without making a blip on most geeks radar screens.

I like that Mr. Hook has experience writing portable software. This matched with his authorship of the Portable Open Source Harness (POSH) portability library and his contributions to the Simple Audio Library (SAL) gives a great deal of credence to his writing.

This is a solid "doing" book. Mr. Hook is under no illusion that he's writing an introduction to programming. This book has a consistent purpose to take experienced programmers and fully equip them to deal with portability and it does not deviate from this in the slightest.

The layout of the book is first rate, with clear typography, comfortable spacing, clear diagrams and tables and nicely highlighted callouts. I did not notice any obvious typos or glitches in the book. While the look of a book is not the author's fault if it is below par, a well presented book can enhance the reading and learning experience.

The examples are as realistic as possible. While some of the examples to teach principles might be simpler, they are typically backed up with examples from either the POSH or SAL projects, showing real world portability coding. The level of C/C++ required to understand the examples is higher than many books that I've read. That's not to say that the code seems obfuscated, but it's code that is taking into account aspects of the real world and is, by necessity, not simple. A further positive quality of the code examples is that they're very well explained; well enough that an inexperienced programmer with determination could follow them and come to an understanding.

Appendix B contains a summary of all of the portability rules presented through the book. There are twenty rules and each is reprised with a small explanation/reminder of it's application. An example: Rule 4 - "Never read or write structures monolithically from or to memory. Always read and write structures one element at a time, so that endian, alignment, and size differences are factored out."

If you're looking for more of a fluffy "about" book, then this is not it. This is not a complaint, rather I offer it as something to consider, before you buy what you might otherwise think is a beginner's book.

I must reiterate the non-trivial C/C++ example code the book contains. This book is for serious programmers and is not afraid to role up it's sleeves and cut real code.

This is a very well written and very readable book. There are many aspects to the subject matter of portability and Mr. Hook addresses more of them than many of us had previously suspected existed and addresses them with firm authority. I recommend this book to anyone working with portable code."

You can purchase Write Portable Code from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Kylar writes "When you have spare time and decide to do something with a book (That's like an analog webpage, for the neuronauts among us), how often do you turn to a computer related book? How often has it happened in the last year? Right. The problem being that computer books are often either: a) boring, b) difficult to read, c) poorly written, or possibly: d) made of cheese." Read on for the rest of Kylars' review. Traps, Pitfalls, and Corner Cases - Java Puzzlers author Joshua Bloch, Neal Gafter pages 282 publisher Addison-Wesley rating 9 out of 10 reviewer Tom Byrne ISBN 0-321-33678-X summary 95 Corner cases and traps that any serious java developer should be aware of (or entertained by.)

Java Puzzlers is none of the above(*), being well written, amusing, whimsical, and above all, informative. Bloch and Gafter have brought us a book that entertains us with corner-cases, one-in-a-million chances and other happenings that explore the ins, outs, and guts of the Java Programming Language.

Anyone who has been a serious java programmer in the last several years should know the name Josh Bloch, and more importantly, should have read his book Effective Java. Josh, acting as java's platform architect has been directing and guiding Java into it's current incarnation as a mature, robust (Cue the laughter from the peanut gallery) programming language.

This book primarily references the Java 1.5 programming language, and some of the puzzles are 1.5-specific, although a significant portion of the problems are applicable to previous versions. Also, this book is aimed towards people who are competent-to-expert java programmers, and although there is a lot of good information, people who are new to Java will probably be a bit lost. As it stands, I have 7 years of Java experience, and I was only able to figure out about 15% of the puzzles without resorting to code, or more frequently the answer. The reason that I didn't stop to try out most of these problems is that the book is eminently readable, and difficult to put down (unusual for a computer book, and doubly so for one that delves deeply into a language specification document.)

This book dives into a lot of esoteric bits of the Java Language Specification, also known as "The Big Paper That Sometimes Tells Us Why Java Acts Like That," and there are lots of bits in there that don't even make sense, let alone seem intuitive.

Divided into 10 parts, each part presents a series of different code problems that usually present a small method or class that looks innocuous, but in reality exposes a piece of behavior that is strange, spectacular, or, more often, completely confusing. The book exposes flaws in the language, including one of my personal pet peeves, their inability to have a consistent Date object, and this is noted in Puzzle 62 by my favorite line in the book: "The lesson for API designers is: If you can't get it right the first time, at least get it right the second..."

One topic that I found was a continually recurring theme had to do with handling primitives and what happens when they are cast into different types. Java provides a lot of ways to deal with primitives, and for the most part, they play nicely with each other. There are several occurrences that really surprised me. A perfect example is the following innocent statements:

byte b = -1;
char c = (char)b;

so c=-1, right? Wrong. Places like this are things that you could potentially knock your head against the wall trying to figure out why something doesn't do what it appears to do.
(In this case, byte is signed, char isn't, and the widening cast fills in bits, leaving c=65535.)

A good job is also done describing best-practices for API and library designers, as well as us, the more mundane programmers.

The only downside (from my background and point of view - that of an applications architect, and not generally as a language or API designer) - is that some of the amazing optical illustrations can cause dizziness and nausea - although I can't guarantee that won't happen by the loops and twists that your mind will be tied into because of the puzzles.

Lastly, Bloch & Gafter include an appendix that serves as a summary to all the pitfalls and traps that are introduced in the book, and almost could be an appendix to Bloch's 'Effective Java'.

The bottom line is that in reading this book I learned a fair amount about several edge cases and issues that I had actually encountered - and it increased my understanding as to HOW java does things - although I'm fairly certain that I'll never understand the WHY. And most of all - I enjoyed this book, from start to finish, and that's rare, and worth the time.

You can purchase Java Puzzlers from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

ewuehler writes "I don't think I've ever heard a security application, be it a consumer anti-virus application or an enterprise IPS application, described as "user-friendly" or "easy to use". When I read the title of the O'Reilly book Security and Usability: Designing Secure Systems That People Can Use, I took the bait and requested a copy for review. The title could also double as my current job description, so I was equally interested from a "job education" point of view. The book is a collection of (mostly) academic articles, grouped in sections and chapters. Each article/chapter is written by different authors; from Bruce Tognazzini who founded Apple's Human Interface Group to Blake Ross of Firefox fame to names previously unknown to me. Read on for ewuehlers' review. Security and Usability author Edited by Lorrie Faith Cranor & Simson Garfinkel pages 714 publisher O'Reilly rating 8 reviewer Eric Wuehler ISBN 0-596-00827-9 summary Designing Secure Systems That People Can Use

Along with the variety of authors, their backgrounds are equally diverse. The majority of the articles come from academia, with a few corporate names and open source authors. While not exclusively US authors, the majority of the articles come from US institutions. Generally, I would expect the "new author every chapter" approach to be a distraction, but the editors have done a good job at grouping the articles and cross-referencing chapters where appropriate. However, I did not find this a cover-to-cover read, the book lends itself well to "flipping and skipping" around.

The editors claim the goal of the book is "first for researchers in the field of security of usability, then for students, and finally for professionals." While I fit in the "professionals" category (not a term I'd use, but I had to pick one of the three), I found the information very helpful and educational with respect to my current job. With a majority of the chapters coming from an academic perspective, there is room for debate and interpretation of the conclusions. For example, several chapters discuss the fallibility of passwords, making it obvious the issue of password security is not just simply whether or not to write them down.

The book is divided into six parts. The first, Realigning Usability and Security, introduces the premise of the book. These five chapters discuss the importance of usability when designing security applications. It is well known that the human element is "the weakest link in the chain" of system security. For example, "Kevin Mitnick revealed that he hardly ever cracked a password, because it 'was easier to dupe people into revealing it' by employing a range of social engineering techniques. He points out that to date, attackers have paid more attention to the human element in security than security designers have." The implication being the less usable the security, the less likely it will be used correctly, no matter how good it actually is. The chapters go on to describe different processes for designing usable secure systems and applications.

The Authentication Mechanisms section discusses the usability requirements around passwords and other authentication techniques. The information in this section dealt more with implementation than theory as compared to the other sections. The expected chapters covering the prevailing forms of authentication; text passwords, challenge questions, graphical passwords, and biometrics are there. I found most interesting the chapter Identifying Users from Their Typing Patterns. This refers to "keystroke biometrics" which "seeks to identify individuals by their typing characteristics." The concept has been around for a while and first suggested for identification in 1975. (Random fact I found interesting, it finds its roots in 19th century telegraph operators who could often identify each other by listening to the rhythm of each individual's Morse code keying pattern.) Despite the fact that the concept has been around for quite a while, it does not seem to appear much on the authentication mechanism radar.

Secure Systems is the "make or break" section covering the secure user experience. These chapters cover things such as fighting "phishing" at the user interface, making PKI easy, and "deleting" files vs. really deleting files. One of the more interesting chapters looks at security tools and practices based on ethnographic field studies. While ethnography (the study of customs of individual peoples and cultures) initially does not sound like a "security or usability" issue, it is used (and the author claims quite effectively) to understand "the work practices of computer users in context, informing the design of computer systems to better suit their needs."

The section Privacy and Anonymity Systems contains a chapter discussing Google's Gmail privacy policy with respect to "informed consent". For the most part, the authors give Gmail high marks, with the privacy concerns rooted in differing definitions of "privacy". For example, if you believe that content-targeted advertisements should require the consent of all parties involved, you (in sending an email to a Gmail user) have not consented to the targeted ads the recipient sees. The chapter describes two other cases of informed consent and presents a list of ten design principles based on the information. Another chapter discusses leveraging social processes for managing browser cookies. The concept being when a cookie is saved stored, it will provide you aggregate community data such as X percent of the people visiting this site blocked the cookie. One obvious benefit is the ability to educate "less knowledgeable" users about "good" cookies vs "bad" cookies.

The remaining sections discuss usability of products, for which the chapter titles are description enough. Overall, I found the book useful. The variety of authors and subject matter made it easy to skip around and choose what piqued my interest at the time. Along with the academic feel of the book, each chapter is generally descriptive enough to get an idea as to what subject matter will be covered. While the book's target is "researchers and students" first, as a "professional" working for a security company, I found it helped me better explain the pros and cons of these topics to the less technical people I work with every day. I'd recommend it to anyone involved with the usability of security applications and systems."

You can purchase Security and Usability from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

jsuda writes "The Definitive Guide to MYSQL 3rd Edition certainly deserves its title. It is a large, dense, complete guide to MySQL and updates its predecessor edition by covering new MySQL5 and new auxiliary software including database administration tools and interfaces. MySQL is the open-source database software which has become very popular for web-based database applications now being used by Yahoo, NASA, Slashdot, and other entities. Read on for the rest of Jsudas' review The Definitive Guide to MySQL 5 3rd Edition author Michael Kofler pages 748 publisher Apress rating 7 reviewer John Suda ISBN 1-59059-535-1 summary The Definitive Guide to Mysql 5

The author of this book, Michael Kofler, has a Ph.D. degree in computer science and is an accomplished writer of technical books. The audience is intermediate to high-level database designers and programmers. Although the presentation assumes little prior knowledge of MySQL and databases, it does assume a good amount of contact with and knowledge of programming languages. The topic of this book does not lend itself to an easy, flowing writing style. Reading through this complex material is like chewing on heavy New England pound cake. That is not a criticism of the author as he thoroughly presents the topics in a comprehensive, workmanlike, textbook-like manner. The discussions of databases and MySQL features are lightened by numerous table, charts, graphics, and examples of relevant matters.

The updating from the 2nd Edition of The Definitive Guide involves the upgrade of MySQL from version 4.1 to 5.0 which now provides support for Unicode, the sub-SELECT and GIS functions, improved authorization features, addition of stored procedures, and other new commands and server options. It also includes discussion of new or updated auxiliary software used with MySQL, like PHPAdmin and new interfaces for Open Office, Star Office, and Apo.NET.

There are six parts with twenty-three chapters and 3 appendices, amounting to 748 pages with index. The parts entail an introduction to MySQL and databases, administrative tools and user interfaces, fundamentals of database design, programming using MySQL, and detailed content references. The appendices include short segments of a glossary, bibliography, and notes about the sample code files available for downloading from the publisher's website at http://www.apress.com./

The beginning chapters introduce the basic concepts of MySQL including its client-server architecture, tables, fields, queries, keys, and the distinction between relational and object-oriented databases. The author focuses the bulk of the book on relational databases. The many features of MySQL are itemized and other matters like licensing and setting up test environments are discussed. A large segment of this early material offers instruction on installing under Windows and Unix/Linux platforms and configuring the installations for function, usability, and security. An introductory example of building an opinion poll application with PHP is provided.

Chapters 4 - 6 cover a number of administrative tools to use with MySQL, including mysqladmin, mysqldump, and PHPAdmin. The author spells out how to install and configure, set up user management and security, create and edit databases, import and export data, and use auxiliary functions, among other things.

The best chapter, in my view, is Chapter 8 on database design. The technical aspects of databases are well-covered, like the various table types and data types, but the more theoretical aspects are noted in some length. There is some art in creating databases and tables which is above the technological. Correct design with related tables is crucial to efficiency, ease of use, accuracy, ability to revise, and consistency. A segment on "tips and tricks" in database design is especially interesting.

The bulk of Part 3 contains a comprehensive presentation of SQL features, syntax, configuration, and security issues, The new functions of version 5 are explored, like GIS and stored procedures and triggers. A section on transactions for advanced users and setups is nicely done. For novice users, mention is made of the "--I-am-a-dummy" option which warns and provides a second chance to avoid inadvertent updating or deleting of a table. Chapter 14 is all about maintenance issues - backing up, importing, logging, and replication.

Part 4 deals with how to combine MySQL with programming languages like PHP, perl, Java, C, Visual Basic, and Visual Basic.NET. Each is treated similarly - detailing features, concepts, syntax, and programming techniques. Most of the attention is given to PHP, which is described as a natural companion to MySQL for use in developing dynamic web applications.

Chapter 21 is a comprehensive SQL reference of operations, functions, data types, variables and constants, and commands. There are a large number of charts and tables to bring order to the dense material. Chapter 23 contains material on the various API's which can interact with MySQL. These include PHP.API, perl.API, JDBC, ADO-net, and C.API.

For those with a need to know, and those with a desire to learn MySQL, this volume contains nearly everything you would want and expect, not only about MySQL itself but about the software that interacts with it or web servers. The author deserves credit for presenting the dense material in a thorough and orderly manner."

You can purchase The Definitive Guide to MySQL 5 3rd Edition from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

clampe writes " In Everything Bad Is Good For You: How Today's Popular Culture is Actually Making Us Smarter, Steven Johnson tries to convince the reader that video games, television and the Internet are good for us, despite critics who talk about "vast Wastelands" and "infantilized societies". The book raises interesting questions, but in the end is a lightweight analysis that is better for engendering sound bites on NPR and The Daily Show than for convincing serious readers." Read on for Clampes' review. Everything Bad Is Good For You: How Today's Popular Culture is Actually Making Us Smarter author Steven Johnson pages 238 publisher Riverhead Books rating 7 reviewer clampe ISBN 1-57322-307-7 summary Popular culture may have a role in making people smarter

In "Everything Bad Is Good For You" Johnson argues that major forms of entertainment like television, video games, films and the Internet have grown increasingly complex over the past several decades, which corresponds to an increase in average IQ scores in the U.S.

The introduction to the book summarizes cultural criticisms about the growing banality of entertainment, focusing mostly on television. Johnson uses this springboard to state his thesis: that popular culture is not only growing more complex, but that the complexity is making consumers of pop culture more intelligent.

The main content of the book is divided into two main parts, with the first arguing that video games, television, the Internet and movies have grown more complex in recent years, and the second part outlining the relationship between those forms of entertainment and increased intelligence.

Johnson claims that the complexity of problem solving and exploration involved in current video games help players learn critical thinking skills. He amusingly asks the readers to consider a world where video games have been around for centuries and a new technology called the book is all the rage. The cultural critics currently bagging on video games would claim books are static, isolating and understimulating. Johnson is the first to admit he's usng hyperbole here, and books obviously have value, but the point is made. Video games, he points out, cannot be directly compared to books in terms of the types of intelligence they encourage. Video games, according to Johnson, are valuable because they force players to make choices, solve problems, keep track of varied situations and in some cases cooperate with others.

Criticizing television is a popular straw man activity for cultural critics. The boob-tube, the idiot box, the vast wasteland. Johnson argues that while the general thinking is TV has gotten worse over the past 30 years, it in fact has become much better. Current shows have more complex narratives, trust viewers to catch subtle references and have denser social networks. Johnson compares "Dragnet" to "Starsky and Hutch" to "Hill Street Blues" to "The Sopranos" to show the evolving complexity of narratives in television dramas. Even reality TV, the easiest target around, is more complex compared to it's historical antecedent, the game show.

The Internet is valuable in three ways according to Johnson: by virtue of being participatory, by forcing users to learn new interfaces and by creating new channels for social interaction. Johnson provides a laundry list of online interactions that bring people together and make them smarter.

Johnson gives a "qualified yes" to the proposition that movies have undergone the same transformation as television. His main evidence is the increase in the number of characters to be found in "The Lord of the Rings" trilogy compared to the original "Star Wars" trilogy. The other main evidence is the development of a sub-genre of films he calls "mind-benders" typified by Kaufman works like "Being John Malkovich".

In Part 2 of the book, Johnson associates research that shows American IQ scores have risen over the past several decades (the Flynn Effect) with the increased complexity of popular culture. He looks at alternative explanations for this trend, such as nutrition and education, dismissing each in favor of the popular culture explanation.

The Good:
There is something about people who say they never watch TV that makes me want to punch them. I'm also a little tired of having to explain at dinner parties and family gatherings that my playing video games does not mean I went ahead with the lobotomy. Johnson seems to have tapped into a real feeling that television and games are not the worthless pastimes that popular media decries them as. The book raises interesting and important questions, while providing a tonic against cultural nay-sayers.

As in previous works like Emergence, Johnson has an engaging and approachable writing style. He blends personal experience and decent explanations of the literature to craft his arguments in an engaging manner.

The Bad:
The main problem with this book is the strength of the claims made in Part 2. Human intelligence is a complex mechanism affected by a blend of genetic and environmental factors. It is possible that games and television play a role in positively affecting intelligence, but Johnson has not strongly made that case here. The data he presents, while intriguing, are correlational at best and arbitrary at worst. Johnson is actually careful to qualify the populations he considers to be affected by popular culture, and the kinds of intelligence he is talking about. However, the arguments still hang together on fragile strings of "It could be" and "it's not like because of this".

For example, it could be that his selection of television shows to compare biases his analysis. What Johnson says about the increased complexity of television narratives seems intuitively true, but there's danger in the kind of analysis where shows are plucked with no clear selection mechanism from the past and we draw such sweeping conclusions from them.

There are also several alternative explanations to the trends pointed out in this book. For example, let's assume that there is more worthwhile television than there used to be. However, the real comparison should be between worthwhile television compared over the total amount of television available. Given the explosion of television programming since Starsky and Hutch, it's not surprising that better shows are available. Another explanation might be the maturation of the media. Literature is the gold standard here to some extent, but the novel is an older media form that has had many opportunities to attract good authors than television and video games. Over the centuries that we've had novels, we accumulated some talented authors, and those luminaries attract other talented individuals. Television and video games are a newer media, and consequently haven't accumulated as many giants. Some of Johnson's examples of the new complexity in television and film are really examples of a couple of special individuals, like Aaron Sorkin and Charlie Kaufman, attracted to an increasingly mature art form.

The above counter-examples show some of the dangers of this case based argumentation at the center of this book. By using pseudo-case studies, there isn't really a basis by which the data presented by Johnson is stronger than "because I said so." Work that would help his argument has been done in communication studies, developmental psychology and cognitive psychology, but those fields are largely ignored here. Instead, cranky old guys like Marshall McLuhan and Neil Postman are set up as straw men. This disconnect reminds of how well Howard Rheingold incorporates current research into popular press efforts like this book. Johnson does use some decent resources like James Paul Gee, and seems to be widely read in several cogent fields, but it doesn't seem reflected as well as might be expected in the actual text.

The sections on the Internet and movies are clumsy and seem almost to be afterthoughts to the other sections. The section on video games is stronger, and the book would have been better by concentrating on that element of the story alone. May not have had as cool a title though.

Final recommendation:
This book is fun, light reading. It's not bad as a catalyst for discussion at parties, but as a serious polemic argument it doesn't hold up. Still, the book is a good airplane read, or something for the hammock. But you're better off playing a video game."

You can purchase Everything Bad Is Good For You: How Today's Popular Culture is Actually Making Us Smarter from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

norburym writes "Mark G. Sobell is well known for several comprehensive and well-written volumes: A Practical Guide to Solaris; A Practical Guide to Red Hat Linux: Fedora Core and Red Hat Enterprise Linux (2nd ed.); and A Practical Guide to the Unix System (3rd ed.). It seems only natural for the author to follow these exceptional examples with yet another excellent book entitled A Practical Guide to Linux Commands, Editors, and Shell Programming . Read on for Norburyms' review. A Practical Guide to Linux Commands, Editors, and Shell Programming author Mark G. Sobell pages 1008 publisher Prentice Hall PTR rating 9 reviewer Mary Norbury-Glaser ISBN 0131478230 summary Linux Commands, Editors, & Shell Programming

While the author has covered some aspects of this material in A Practical Guide to Red Hat Linux: Fedora Core and Red Hat Enterprise Linux, there is more than enough here (in-depth coverage of the vim and emacs editors; tcsh; sed and gawk; and the command reference section that comprises Part V) to make this a new and exhaustive volume that should take top dog in anyone's Linux library.

Sobell splits the book into six parts with Chapter 1 acting as a preface to the rest of the book. It gives a history and an overview of Linux and discusses distinctive aspects of the operating system that make it different from others. We've all heard and read the arguments before: Linux is superior to Windows, TCO is lower with Linux, Linux is not proprietary, etc. but Sobell avoids this display of arrogance and superiority by treating the origins and features of Linux as an evolution of best practices and common sense. As such, we're not left with a suspicion that the author has blinders on. To the contrary, the reader can proceed with an open mind to learning the intricacies of Linux and the command line.

Part I isn't geared for experienced users of Unix or Linux but it does serve as a good skimming point for those sysadmins who may need to brush up. For the beginner or the novice, however, these four chapters give a compact and succinct introduction to using Linux and set the stage for the sections to follow. Chapter 2 begins with logging in from a Terminal, including emulation, ssh and telnet. The author explains how to tell which shell the user is running; how to work with the shell; and how to use help, man and info. Chapter 3 is a catalog of basic utilities with all the usual suspects: ls, cat, rm, cp, mv, grep, hostname, head, tail, sort, echo, date, etc.; compressing and archiving tools: bzip2, bunzip2, gzip, tar; locating commands: which, whereis, apropos, slocate; commands used to get user and system information: who, finger, w; and commands used for communication: write, mesg. Sobell gives each utility a brief but thorough description of its function, appropriate syntax and practical uses. Chapter 4 is a complete treatment of the Linux hierarchical filesystem: directory and ordinary files; absolute and relative pathnames; how to work with directories; hard and symbolic links; and access permissions. Chapter 5 is where the reader gets a closer look at the shell. Sobell covers command line syntax (command name, arguments and options), processing and executing the command line, standard input and output (including pipes and a really nice explanation of device files), redirecting standard input and output, running a program in the background and aborting it using kill, generating filenames and expanding pathnames using wildcards/special characters, and utilities built into the shell like echo (and how to list bash and tcsh builtins).

Part I is a comfortable read. It moves along quickly and with quite a bit of information but not so much to overwhelm. By the conclusion of Chapter 5, the beginner or novice can feel pretty competent with the CLI.

Part II is dedicated to the vim editor and the emacs editor, both enjoying a chapter to themselves. Sobell happily avoids adding fuel to the already flaming fire of which editor is "the best." Chapter 6, "The vim Editor," and Chapter 7, "The emacs Editor," both use a tutorial approach to demonstrate the use of each text editor. The author includes a brief history of the development of the editor before giving a fairly complete lesson on creating and editing files within that particular editor. Some highlights of Chapter 6 include: vi clones; details of vim commands like join, yank and put; and advanced editing techniques like using markers and creating macros. Chapter 7 features: an explanation of emacs key notation and key sequences; incremental and nonincremental searches; advanced editing techniques like using the buffer to undo changes; using Mark and establishing a Region; yanking killed text; and manipulating windows (splitting and adjusting, for example).

Learning at least one editor to a level of competency is an absolute must. Sobell provides excellent instruction on both vim and emacs and along with the tutorials and the exercises at the conclusion of each chapter the reader will be sufficiently proficient in both to choose a favorite.

Part III, "The Shells," discusses the Bourne Again Shell (bash) and the TC (tcsh) shell with careful detail to each interpreter/language. The author stresses that bash, rather than tcsh, should be the shell of choice for programming and this is reflected in the instruction set forth in each of these two chapters.

Chapter 8 concentrates on bash: shell basics (startup files, redirecting standard error, simple shell scripts, separating and grouping commands, job control, directory stacks); parameters and variables (shell and user-created variables, variable attributes, keyword variables, special characters); processes (structure, identification); history mechanisms (reexecuting and editing commands, referencing events using !, use of the Readline Library); using aliases; shell functions; controlling bash features and options (using command line options and the set and shopt builtins); and a description of how bash processes the command line (command line expansion).

The TC Shell (tcsh) gets equal attention in Chapter 9. The author aims to show how tcsh differs from bash while providing a broad overview of the shell: shell scripts; entering and leaving tcsh; tcsh startup files; features common to bash and tcsh (and how tcsh implements them in a different manner) including command line expansion (tcsh calls it "substitution"), history, aliases, job control, filename and command substitution, and directory stack manipulation; redirecting standard error using >&; command line (word completion, command line editing, spell correction); variables (substitution, string variables, arrays, numeric variables, using braces, shell variables); control structures (if and goto, interrupt handling using onintr, if...then...else, foreach, while, break and continue, switch); and tcsh builtins.

Part IV, "Programming Tools," is the logical progression from the previous discussions of editors and shell basics. Sobell splits this part over four topics: programming tools, programming bash, gawk and sed.

The focus of Chapter 10 is programming tools. In particular, attention is given to writing and compiling C programs. Sobell shows how to check for your GNU gcc compiler and then gives a C programming example with a simple C program that converts tabs to spaces while maintaining columns. He takes this a step further by compiling his example C program to create an executable file. He also addresses shared libraries, fixing broken binaries, using GNU make to resolve dependencies, debugging techniques, threads, and system calls for filesystem operations and for processes control. I especially like the inclusion of the make utility. Sobell provides a nice graph that shows dependency relationships and uses an example makefile to illustrate dependency lines and construction commands. The rest of the chapter deals with source code management and using the CVS (concurrent versions system) utility and TkCVS (a Tcl/Tk-based GUI to CVS).

The next chapter is a return to bash with more detail to shell programming. The author uses this section to cover control flow contructs (if...then, if...then...else, etc.); file descriptors; more detail on parameters and variables (array variables, locality of variables, special parameters like $$ and $?, positional parameters like $#, $0 and $1-$n); expanding null and unset variables; bash builtin commands (type, read, exec, kill, etc.); and expressions (including a table of bash operators). The chapter concludes with the creation of two example shell programs: a recursive shell script that illustrates recursive operations and a "quiz" shell script which presents questions with multiple choice answers. The author walks through both of these step-by-step and points out potential pitfalls as he creates and executes a working design. Sobell should be congratulated for putting together a well-balanced and complete chapter. The exercises are thoughtfully constructed.

The Gnu awk (gawk) utility and the sed (stream editor) utility complete the final two chapters of the book. Both chapters include syntax, arguments, options and a fair number of examples.

Part V is the command reference section and this constitutes a volume in itself. This is, essentially, a printed version of man pages of utilities and shell builtins. Sobell gives us a bonus above Linux man pages, though: he includes extremely useful and pithy examples with each entry along with interesting discussion and notes sections. I would love to see the "Command Reference" as an electronic, searchable version! Perhaps as a CD included with the book in future, instead of in print.

The Appendixes make up Part VI. Regular expressions used by gawk, sed, vim, emacs, etc. are described in Appendix A. Help options, including Web sites for documentation on Linux systems (GNOME, GNU, KDE, etc.), Linux newsgroups and mailing lists, software packages (CVS, Freshmeat, Sourceforge, Tucows-Linux, etc.), Office suites (AbiWord, KOffice, OpenOffice, etc.), and how to specify a Terminal make up Appendix B. The last appendix shouldn't be ignored or overlooked: Keeping the System Up-To-Date. This section describes yum, Apt and BitTorrent. Kudos to the author for reminding readers to maintain their systems and providing good instructions on how to do so.

A Glossary of terms and the Index conclude the book.

The layout of the book is well designed: the typography is comfortable to read and, although physically hefty, the dimensions of the book give the reader a nicely balanced paperback. Nothing fancy but excellent quality and eminently readable with delineated examples and good font choices.

Every chapter begins with a brief introduction and ends with a chapter summary, exercises, and advanced exercises where appropriate. The exercises are a highlight of the book: Sobell has obviously given these a lot of thought and they are exemplary of the chapter topics that they reference. Answers to even numbered problems can be found at the author's Web site.

Overall, it's hard to find anything to complain about here that wouldn't sound inconsequential and trifling. No mistake, this is a big book: Part V alone (command reference) is a volume in itself. But I can't see anything extraneous or non-essential here. The author combines all the important features and tools together with the appropriate and necessary references.

Sobell has compiled an extensive volume that both newcomers to Linux and experienced users will find extremely useful. Once in hand, A Practical Guide to Linux Commands, Editors, and Shell Programming becomes not only a complete tutorial but also an invaluable resource that will be referenced time and again. This is as close to a textbook as you can get without being tormented by dry sterile language; Mark G. Sobell clearly has a command of his subject and he exudes a passion that infuses his writing and clearly elevates this book above any mere manual. This will become a standard and as such, a "must have" for anyone serious about learning command line scripting.

You can purchase A Practical Guide to Linux Commands, Editors, and Shell Programming from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

A reader writes: "It appears that Neil Gaiman released two of his books (Anansi Boys and American Gods) as books on CD. The interesting twist is that they are being released as MP3 - which for the world of audio books is something pretty new. ". Indeed; MP3 audio books, I think, have given the book publishers the willies because of the DRM issue - anyone else seen this before? And also worth noting that Mirrormask was released in motion picture form and rocks. I think to describe it would be equal parts The Dark Crystal and Myst, combine with Carnivale and a dash of The City of Lost Children.

theodp writes "Does it bother you that churches have a Mission Statement touting their Core Values? That even the CIA has a Vision? In his book Death Sentences: How Clichés, Weasel Words and Management-Speak are Strangling Public Language and in this Newsweek interview, Australian author Don Watson argues it's time to protest the mind-numbing business jargon that infests our schools, churches and political speech. Examples that people have sent to him can be found on Watson's website."

theodp writes "In Johnny Can So Program, CS Prof Norm Matloff calls BS on CNET stories like Can Johnny Still Program? and Can the U.S. Still Compete?, saying it's a shame that CNET fails to cover the real threat to American technological competitiveness, the hidden agendas of Chicken Littles like Jim Foley of the Computing Research Association, David Patterson of the ACM and former Intel CEO Craig Barrett, all of whose organizations have a vested interest in playing the education card."

theodp writes "An Oregon library worker was arrested after selling at least $10,000 worth of stolen library books, CDs and videotapes online in the past six months. The thief, who scanned the Net to find items in demand and went to the library to check them out, was busted after an alert college president noticed his copy of the recently-published I am Charlotte Simmons, purchased on Amazon.com, sported a library receipt with a due date of Dec. 26. Earlier this month, it was reported that a VT man was arrested for stealing hundreds of books from college libraries and bookstores and selling them on Amazon, realizing more than $4,000. The library thefts are somewhat ironic, since Amazon CEO Jeff Bezos and the NY Times seemed to suggest there might be fewer books in libraries if the Authors Guild, who opposed Amazon's used book sales practices, had their way. Bezos also once told angry booksellers there's no reason why Amazon should have to collect sales taxes, arguing that Amazon gets no police services from other states."

A few weeks ago, reader James Mitchell reviewed Malcolm Gladwell's Blink: The Power of Thinking Without Thinking. Now book_reader (Gary Cornell) writes with a very different take on Blink. "When I finished this book I was impressed. Then I blinked -- and realized that I was taken in by its surface attractiveness. After the initial glamour wore off, I was left deeply unsatisfied. This book is over-hyped, and so underperforms. The point of this book can be summed up as: "Trust your intuitions. Well, not quite; trust them, if and only if they are good." Gladwell tells lots of anecdotes to indicate that sometimes less is more. But of course he also tells anecdotes that tell us sometimes less is less." Read on for the rest of Cornell's thoughts on the book. Blink : The Power of Thinking Without Thinking author Malcolm Gladwell pages 288 publisher Little, Brown rating 4 reviewer book_reader ISBN 0316172324 summary Over-rated and over-hyped; lukewarm anecdotes but no real meat.

I wonder why is this book so popular. Any reasonably intelligent person, especially one with a penchant for Dilbert cartoons, already knows what the author is getting at. For example, the (fun) chapter on Warren Harding where Gladwell points out that this terrible president became president because he looked so presidential, is nothing more than the various Dilbert cartoons on "pointy haired boss" writ large. Scott Adams said it better in just a few panels: because we intuitively equate certain kinds of look and feel with positive qualities: tall people do better, beautiful people do better. Or, to put it another way: human beings tend to be shallow and stupid, and prone to letting their unconscious rule them at times when they shouldn't. Why? Because as he says: "our unconscious attitudes may be utterly incompatible with our stated values." (As he points out, the number of women in orchestras went up dramatically when blind auditions became commonplace.) So trusting our intuitions may lead to incorrect conclusion. Except when they don't.

Forget Dilbert cartoons for a second: all this book does is bring attention to a phenomena that should surprise no one, least of all someone who has had any contact with research scientists, research mathematicians or inventive computer scientists. It simply tells us that smart people can have really good intuitions about problems that emerge in a "blink." He then coins a word for this phenomenon: "thin slicing." Whoopee, a new word for an old phenomenon. When I was a research mathematician, we used to call it a "sense of smell." I like our term better, much more concrete.

I can't remember how many times I was sitting in front, or for that matter was myself in front, of a blackboard, writing something down, and overheard people saying "that doesn't smell right," or "that smells good." If it didn't smell right, we took another path to the proof, or made another conjecture. If it did "smell right," we tried to prove it or look it up. How developed your sense of smell made up a great difference in what you accomplished. Trouble is, at least in mathematics, the field I am most familiar with, nobody ever figured out how to develop a person's sense of smell: that's why so few people ever did much research beyond their Ph.D. And nothing in this book will help you do so. Or, take chess: anyone who has watched grandmasters play speed chess and looked at the amazing beauty of some of these games knows that quick pattern matching is one of the keys to their amazing talents. Car salesman who can read people do very well, etc. Intuition is a great thing -- if it is good intuition.

Anyway, I am of course pleased to have discovered that what I and every scientist/mathematician had been doing, probably since the days of Archimedes, is "thin slicing." I'm being a little harsh actually: I did find parts of this book worthwhile: the parts where he describes attempts to algorithmatize good intuition (such as the amazing work by Paul Ekman on teaching the understanding of facial expressions so as to help us see what's really going on "in there"). Of course, this isn't new either: the expert-systems approach to artificial intelligence has tried to do this with varying amounts of success. He highlights what is actually one successful example of this approach in the book without pointing out that this is actually old hat: heart attack detection from the constellation of symptoms that will present themselves in an emergency room. What he doesn't say is that there have been many other interesting approaches for automating the intuitions great clinicians have about medical diagnostics that go back at least thirty years.

So there is some good to this book. We should try not to use the intuitions of the many, but rather understand, learn and ideally, algorithmitize the intuitions of the few. The only trouble is the importance of this was described far more beautifully 90 or so years ago by the great philosopher and mathematician Alfred North Whitehead in one simple paragraph from his great book "An Introduction to Mathematics:

"It is a profoundly erroneous truism, repeated by all copy books and by eminent people when they are making speeches, that we should cultivate the habit of thinking of what we are doing. The precise opposite is the case. Civilization advances by extending the number of important operations which we can perform without thinking about them. Operations of thought are like cavalry charges in a battle--they are strictly limited in number, they require fresh horses, and must only be made at decisive moments."

In sum, this is not so much a bad book as one that is much ado about nothing. "Know that your intuitions can be useful, but take your intuitions with a grain of salt" doesn't seem all that insightful to me. Come to think of it, I think my mother told me this.

I'd go further, actually: calling this is a book is simply to acknowledge its appearance between a single cover: it's essentially a collection of New Yorker articles with all the virtues and vices that that magazine is known for. All the sins of Gladwell's previous best seller The Tipping Point are written larger and are more obvious here. He describes, but gives little insight into the phenomena of intuition. Likewise, he rarely tells you how to take advantage of intuition when it arrives (the fatal flaw of the Tipping Point). Personally I suggest that we try harder to algorithmatize intuitive genius, by those rare individuals who have it, and thus follow Whitehead's intuition on how to make civilization progress.

You can purchase Blink: The Power of Thinking Without Thinking from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

We've reviewed Wall Street Meat, by Andy Kessler. Andy's recently released Running Money. Andy sent this piece on to us, and it's one that I think will be appreciated.

"You can't wear jeans," the woman at the United Airlines counter told me.

"What was that?" I asked.

"I'm sorry, we have rules and codes of conduct to adhere to. I can't let you sit in First Class wearing jeans."

"Really?" I had a cheap suit in my bag, but the last thing I wanted to do was dash into some phone booth and change into super executive so I could fly to Chicago.

"We can't have some sort of riff-raff in our premium sections."

"Well, I'm headed to a--"

"This is United Airlines, global leaders in air travel and destinations."

"I'm interv--"

"Just a second. Your record is flashing red. This is very odd. Are you some sort of VIP?"

"I like to think so, but I don't think too many beyond my mother would agree."

"Well someone at United Airlines thinks so. Your record has been flagged and the ticket comped. I don't think I've ever seen one like this. Family members get comped, but something is going on here with your record. Here you go, seat 2B. Or is that 'not to be,' tee-hee. Enjoy your flight."

She then whispered, "Next time, please don't wear jeans -- we have standards here."

"OK, got it," I whispered back.

"And welcome to the Friendly Skies," she shot back.

Actually, I was headed to a job interview at United Airlines outside of Chicago. I was a 26-year-old techie, and could not have cared less about United. But they were nice enough to provide a round trip first class ticket to Chicago, where my girlfriend Nancy happened to live, and I was tired of paying up for the 771-mile trip.

On board, I sat next to a pilot who told me he was jealous that I got to wear jeans in First Class. I saved the "I'm interviewing" line just in case he started harassing me, but he couldn't have been a nicer guy.

Chicago, Illinois: Spring 1985 "Hello, welcome to United Airlines. Thanks for coming out all this way. I'm sure you have a very busy schedule, I appreciate your time."

"Not a problem, I have been looking forward to this visit to Chicago."

"Great. Oh, I should introduce myself. I'm Norm Poole. I haven't been here that long, six months or so. I was hired with the task of updating United's computer systems. It's pretty antiquated stuff around here. You're from Bell Labs, right?"

"Yes -- Holmdel."

"Great. I saw that on your resume, that's why you're here. Actually, my son is also with the Labs, out here at Indian Hill."

"I doubt I know him, it's a big place."

"OK then, let's head back to my office. It's a bit of a hike. They don't care too much for us tech types." Norm and I proceeded to walk what seemed like a quarter mile through United's building.

"You know that United is building a new terminal at O'Hare?"

"I think I read something about that."

"Yeah, it is loosely based on the Great Crystal Palace of Victorian England fame, 1850-something."

"In what way?" I asked.

"As far as I can tell, lots of glass."

"I like watching the planes take off and land."

"Most people do, calms the nerves. Actually, the Crystal Palace was part of the Great Exhibition that showed off all the accomplishments of England and its colonies. So the powers that be around here want the new terminal to be as high tech as possible, to show off their constant path towards progress, a â Now is the Time' sort of thing."

"Isn't that the tag line of the GE Carousel of Progress at Disneyland?"

"Probably. Wasn't it the World's Fair? No matter. We'll show off our advanced thinking."

"How is that?" I asked

."Lots of computer monitors, maybe even in color. Plus, we have to figure out some scheme to move data around without wires. The architect has already placed all the glass and forgot we might need wires. Wires are pretty ugly, so my group has to fix the design flaws with some wireless technology."

We wound our way through the building talking about computers and networking. I realize later that the interview had already started, but I was too busy talking in the sights.

"So, you know a lot about the UNIX operating system?" Norm asked.

"Sure, I use it, and I can program in C." I answered.

"Great. That's what we use around here."

We kept cutting through these large rooms with giant tables in the middle of them.

"Personally, I prefer VAXes. UNIX machines are always crashing."

"OK, Andy. This is an airline. There is an unwritten rule to not use that word."

"Which word?"

"The C-word."

"Oh, I get it, sorry. I find that UNIX machines are ... are prone to unscheduled service disruptions."

"There you go. You'll fit in here well."

As we walked through more of these rooms, I kept noticing what looked like airline tickets stacked in foot-high piles all over these massive tables. Workers (almost exclusively women, but of all ages), were gabbing away while flipping through these piles of tickets. It seemed like United Airlines Global Headquarters had dozens of these rooms, with stacks and stacks and stacks of these tickets.

"Can I ask you something?" I asked.

"Sure. Fire away." Norm answered.

"What's with those giant tables and all those women?"

Norm started to chuckle. "Oh that? Ticket sorting. It's sort of the dirty little secret of the airline business. We can get people on and off planes, and fly them to where they need to go, but then we have to sort all their damn tickets."

"Don't you just throw them out after the flight takes off?" There were no depths to my personal naivete.

"We wish. Every single ticket is flown back to headquarters to be processed. First we have to strip out our competitors tickets, which we accept for payment, and then settle with them."

"Aren't they a different color or something?"

"That would make it too easy, but not a bad idea. Once their tickets are gone, we have to sort our own tickets and match them against the flight manifests to make sure everyone actually paid, measure yield and load and all those other things that schedulers like to know about."

"Wow, sounds like a really boring job."

"I'm sure it is. Most of these people are high-school grads, and maybe a few dropouts. You don't have to be a rocket scientist to sort tickets, but you've got to be literate."

"But this is 1985. Shouldn't this stuff be automated somehow?"

"You're kidding right? There is a room full of Ph.Ds who sit around and figure out just how to code those stupid tickets, so when we get them back, we know where they came from. Each ticket is touched something like fifteen times from the time we collect it at the airport until we are done with our sorting and accounting."

"But isn't it expensive?"

"Probably 20 bucks per ticket. I've only been here for six months, but as far as I can tell, the airline industry is not that concerned about costs. First, they -- er, we -- can just raise prices. You pay the $20, not us. Second, if we took one olive out of each salad we serve on every flight, we could save a half a million bucks a year. Sorting tickets is a necessary evil."

"Still ... "

"I know, I know. I agree. If I were in charge, that is the first thing I would attack. Get rid of the stupid tickets. But my priority, my mandate, is to make the Crystal Palace at O'Hare seem high tech."

We walked through four or five more of these rooms, and I started thinking hitting rocks with a sledgehammer all day was more interesting than running an airline.

"OK, we're finally here."

Not me.

* * *

It wasn't hard to solve United's paper shuffle. In fact, the technology had been around for over a decade -- the same stuff that saved Wall Street.

It was the modern computer that helped create the modern stock market. In fact, they grew up together: Wall Street provided the capital for the computer industry to create faster machines to handle Wall Street's growing computing needs. Wall Street used to be a collection of people, but as computers insinuated their way into every crack and crevice, it changed the business of raising and managing risk capital.

In 1949, punch cards, introduced by Herman Hollerith as a record-keeping unit to speed up the 1890 census, were finally used to record trades. Can you hear IBM salivating? In 1950, electronic computers started doing the sorting of trades; in 1961 magnetic tape stored data; in 1964 computers were used to clear certain trades by matching records. IBM computers were indispensable to Wall Street, and Wall Street bid their stock up to provide IBM as much capital as it needed to grow.

As volume and profits grew, more Wall Street partnerships were created to get in on the game. By the 1960s, electronic message switchboards replaced those pneumatic tubes of 1918 so order entry and execution confirmation could happen in something close to real time. Of course, this was to the advantage of the traders -- to be able to get the most current feel for the market; customers were still out of that loop. But the back office was neglected, stock certificates still had to be collected and distributed. Wall Street hit a wall in 1968, and for many it was fatal. Electronics facilitated trading but did nothing to help clearing and making sure buyers got certificates from the sellers.

As volume increased, by some 30% a year in both 1967 and 1968, the people-intensive clearing process took forever. Certificates piled up to the ceiling tiles at brokerage firms, either awaiting payment or as errors and bad trades yet to be reconciled. Hiring more people barely helped. Firms would work 24 hours a day, 7 days a week and still fall behind. Customers simply stopped paying since they stopped getting their certificates. The NYSE began closing one day a week to catch up. They mandated a Central Certificate Service that created electronic certificates for a few stocks so settlement and clearing could happen without handling physical certificates. It was too little, too late. 160 NYSE member firms went belly up in 1969 and 1970, their credit squeezed as it took so long to process the volume of trades, victims of their own success. It was a big problem for those not tech savvy.

* * *

Small companies, who couldn't afford the NYSE or didn't have the size or pristine balance sheets needed to be listed, could have their stocks traded off-exchange, or OTC, over-the-counter. Until 1961, it was a pretty sleazy business: trading was thin, quotes were by appointment, spreads were at the whim of one or two traders. In 1961, the SEC empowered the National Association of Security Dealers or NASD to automate the trading of these OTC stocks. Pretty impressive for 1961. (Of course, it took until 1971 for the first NASDAQ stock to trade, as lots of new technology clearly needed to be invented.)

But capital raising on Wall Street was typically for blue chips only. It merely required a handful of phone calls. "We are raising $200 million for a new line of yellow cheese for Kraft, how many shares can I write you down for?" Tech deals were almost impossible to sell that way. It's not so much that investors wanted equal access, it's that the only way high tech could be sold was to explain it face to face.

One neat company was waltzed around that made these strange devices named I2102s, which were one kilobit of static memory made with a planar process; these static memory units were rapidly replacing core memory in IBM computers.This company also had a new "micro" processor used in some Japanese calculators. Yup, in 1971, Intel had a lot of explaining to do.

The phone didn't cut it, and so they had to visit institutional investors in their offices across the country to sell their Initial Public Offering. The IPO road show was thus invented by C.E. Unterberg Towbin to raise money for futuristic and hard-to-explain technology companies. Now all companies have to go through this grueling ritual. But Wall Street was all too happy to take these new companies out -- IPOs paid 7% fees, and still do.

In May 1973, a new entity took over the clearing process: The Depository Trust Company, or DTC, with the help of IBM using cheaper Intel memory, quickly created a system of electronic record transfer of ownership, replacing the sorting tables. 16 million shares were trading every day, 4,729 different companies had their shares registered with the DTC, and the back-office paper crunch soon ended. With an automated back office, liquidity went up and the risk of investing on Wall Street went down. This is a subtle and critical point, but lower risk on Wall Street meant more risk capital could be deployed in the economy and Silicon Valley started heading down the runway for takeoff.

* * *

For 25 more years, most traditional investors missed the big move in technology stocks, until they all rushed in on the same day in January, 1999. Hedge funds were too busy playing with currencies, especially a lucrative yen-carry trade that blew up in October 1998. Julian Robertson's Tiger Fund had only one saving grace in 1999 -- a huge position in US Air. It was a value stock, and Julian Robertson had bought it right. By May of 2000, United Airlines had made a $60 cash bid for US Scare-lines. Tiger was sitting pretty, despite a tough year of withdrawals: $20 billion in assets dropped to about $6 billion. But with the airline merger, Tiger showed a gain for 1999. But, Julian Robertson joined a long line of old dogs chasing fire hydrants. Once deregulated, airlines were protected by the complexity of their back office. Anyone could refuel and fly a plane, but it took a special organization to sort the paper tickets. In fact, like United, you could buy other airlines and sort their tickets too, saving zillions.

But when technology ended the paper trail and e-tickets came of age, it wasn't the existing airlines that benefited. New players like Southwest and JetBlue could enter the business cheaply. A couple of million bucks in servers and broadband was all the back office they needed. Tthe sorting tables were a thing of the past. It was like taking candy from a baby for these new guys to take market share from unionized United or US Air with their Vietnam-era pilots and aging battle-ax flight attendants.

Withdrawals were relentless, so Julian Robertson closed Tiger in March of 2000, holding onto a few shares he thought would do well, like US Air. Oopsy - US Airline filed for bankruptcy in August of 2002, its stock a children's shoe size of 2 or 3 compared to the mature $60 United offered and withdrew. He should have paid attention to those folks in Silicon Valley.

JFK: Winter 2003 The Van Wyck was backed up, as usual. I hated the trip out of Manhattan to JFK, except I was headed back to SFO. I was running late, it was raining, I was lucky to even get a cab at all, and now I'm crawling down what should never have been named an Expressway. Most cabbies know how to cut through the borough by taking Woodhaven Boulevard. My grandmother used to live somewhere along it, near Cross Bay Boulevard, but I would lose at Queens Monopoly.

We finally hit JFK, and I threw $50 to the driver and ran out to check in. I think I had just enough time to get frisked by airport security, buy a NY Post, and get on the plane. I just hope there was no line at check in. I always got stuck behind some family headed to Moomba via Dallas and Frankfurt.

But just inside the door, instead of a line, there were five kiosks. Nice touch screen displays lined up in a row with United's logo blinking away. This I had never seen before. It prompted for my United Mileage Plus card, which I kept handy for upgrades to First Class. I swiped away and my reservation instantly popped up.

"Do you need any help?"

"Excuse me?"

A nice middle-aged woman with a Queens accent smiled. "I just wanted to know if you needed any help with these machines."

"No, I've got it figured out." I had read somewhere that with these kiosks, United dropped the cost of ticket handling from $20 to under $1.

"Well, don't figure it out too well. Some of us need the work." She smiled again, but I could tell she would just have soon picked up a nearby fire extinguisher and smashed all five kiosks in a heartbeat.

"I understand." I nodded. It had been not quite twenty years since was a stowaway in United First Class under the pretext of an interview, saw the groaning tables in Chicago.

"Well, welcome to the Friendly Skies."

She smiled again and didn't give me any grief about wearing jeans.

editingwhiz writes "IT Manager's Journal has a good look at a forthcoming book, The Linux Enterprise Cluster, that explains in clear, concise language how to build a Linux enterprise cluster using open source tools. Writer Elizabeth Ferranini interviews author Karl Kopper in a Q&A. Is this more complicated than it appears to be? (IT Manager's Journal is part of OSTG.)"

theodp writes "BusinessWeek discusses They Made America, a new book which claims Bill Gates got the rewards due Gary Kildall. The book attacks the reputations of key early PC era players - Gates, IBM, and QDOS programmer Tim Paterson - asserting that Paterson copied parts of Kildall's CP/M and that IBM tricked Kildall, allowing Gates to prevail and depriving Kildall of untold riches and credit for a seminal role in the PC revolution. Some material came from an unpublished memoir penned by Kildall after the University of Washington, where Kildall earned a PhD, picked Harvard dropout Gates as keynote speaker for the 25th anniversary of its CS program."

simonmsh writes "The article Cromwell's moonshot: how one Jacobean scientist tried to kick off the space race describes 17th century plans to build a space chariot out of springs, feathers and gunpowder. The design was based on the idea that gravity disappeared at an altitude of 20 miles, which was called into question by Hooke ^? and Boyle ^? 's work. It sounds like the plot of a Neal Stephenson book." Said book, and its sequels are phenomenal.