Slashdot Mirror

Daniel Shefer writes "Joel on Software is a collection of essays from the Joel Spolsky's Joel on Software web log. Spolsky is also the author of User Interface Design for Programmers (previously reviewed on Slashdot) and is the principal of Fog Creek Software. In this book, Spolsky distills his technical knowledge, wit, and years of experience into an engaging collection of essays on programmers, programming and the software world. Spolsky covers everything from the technical aspects of writing code to software project management, and even offers insights into software marketing." Read on for the rest of Shefer's review. Joel On Software author Joel Spolsky pages 362 publisher Apress rating 9.5 reviewer Daniel Shefer ISBN 1590593898 summary Great insights into programming, software in general and how to do it right.

The essays in this book are even-handed. While he focuses on Windows, Spolsky is not a fanatic believer in one approach over another; if C# works better than Visual Basic for a specific task, so be it. His approach is refreshing when so much is written by opinionated members of the "Microsoft is the source of all evil" camp.

Spolsky starts with down-to-earth topics, such as how to estimate the length of time programming tasks will require, and the ratio of QA people to developers needed for a healthy product. He then moves on to share his thoughts on managing developers and higher-level software-related issues.

One of the book's opening salvos, "the Joel Test for Better Code," is a simple "irresponsible" test that Spolsky created to provide insight into how well a development organization is functioning. The test looks for things like using source-code control, and having testers create daily builds with a single click of a button. As someone who has worked companies that would have failed the "Joel Test" miserably, I can attest to the importance of these criteria.

The chapter on Unicode is a short and to-the-point overview on the topic and should be required reading for any software developer and product manager who wants an introduction to Unicode.

Clean and bug-free code is a common thread in several essays in the first part of the book. Spolsky explains the inappropriateness of developers performing QA and stresses the need to "eat your own dog food." Having developers conduct testing is a waste of resources and upsets them just the same; forcing developers to use their own product will motivate them to create a better one.

In "Fire and Motion," Spolsky takes issue with the "architect astronauts" who generate vague technology announcements that are often counterproductive by creating fear, uncertainty and doubt. While these announcements may drive competitors to waste cycles in converting their code base to the latest technology, they offer no real substance. Misguided companies, mesmerized by the promise of new technologies or by demands from numskull customers, can sap years of developer time when product improvement should have taken precedence.

In "Biculturalism," Spolsky dispassionately discusses the differences in world view between Windows and UNIX programmers. Spolsky probably rankled some UNIX fans, but I share his perspective. Spolsky points out that UNIX developers are just as smart as Windows developers, but when it comes to understanding their end users and having empathy for customers, they tend to fall short.

The "Gorilla Guide to Interviewing" is relevant to all hiring managers. Spolsky describes some of the traits of his ideal hires. Those who, in one sentence, are both smart and "get things done." Spolsky believes in hiring people that can perform multiple roles. Spolsky believes in making a "sharp" decision about the candidate, and finds insulting that a hiring manager would not find the interviewee good enough for his own team but would refer him to another team. Spolsky shares one of his hiring secrets: never hire a "maybe." This might seem obvious, but he details why it's better to reject a good candidate than to hire a bad one. Firing can cost a lot of money, time and effort. Additionally, Spolsky suggests questions to ask during an interview and the necessary "what not to ask."

The "Iceberg Secret Revealed" discusses the manner in which customers express their pain, and points out that customers often don't really know what they want. It is the product manager's job to find a solution that will solve their customer's pain while keeping an eye on the market she is addressing. Just listening to customers without proper filters, is as Spolsky points out, a recipe for disaster. And the Iceberg Secret? Spolsky illustrates in five different ways how customers and stakeholders only look at the tip of the iceberg, and not at the substance beneath it.

In one of the shorter chapters, a missive on measurement, Spolsky addresses the prickly issue of measuring performance in companies. In addition to his own insights on measuring performance, he recommends Measuring and Managing Performance in Organizations by Robert Austin. I will add that to my reading list.

Spolsky wrote an introduction to In Search of Stupidity . He offers there the "geek's" perspective on what it takes to make a successful software company, taking as a starting point the ten largest software companies in 1984 and the equivalent list of 2001. His conclusion is that "no software company can succeed unless a programmer is at the helm." With his usual even handedness, he is quick to point out some of the debacles programmers are responsible for. In the example he gives, Netscape's disastrous rewriting of their code base and almost complete loss of market share while they were doing it. His bottom line? To succeed, a company needs a management team that love and thoroughly understand programming and understand and love business. Not as easy as it sounds.

In his five "Strategy Letters," Spolsky writes about issues that are relevant to anyone making strategic business decisions in the software industry. He starts with company growth modes by comparing Ben & Jerry's to Amazon. He then discusses the classic "Chicken and the Egg" problem when building new platforms. His example is still relevant -- few will develop .NET-based clients until a large number of end users have the .NET engine installed on their PCs and end users will not install it until there are enough applications that require it. Spolsky moves on to discuss backward compatibility, open source economics and the myth of bloatware.

Spolsky points out that despite the growing size of applications, the cost of disk space has plummeted even faster. This may be true, but Spolsky does not address the programs' resulting sluggishness despite more and more processing power. Spolsky wraps up the essay by dismissing the notion of coming out with a "lite" version for a given software product. I agree that lite versions do not always satisfy everyone, but they can be a great way to keep out low-end competitors from entering the market in addition to a way to introduce customers to the high-end product.

The chapter about Microsoft losing the API war is a classic. Spolsky starts with the seemingly outlandish assertion that Microsoft lost the API war. After apologizing for his "grandiloquence and pomposity," he goes on to build a convincing case that if Microsoft has in fact not lost the war, they are definitely in danger of doing so. He starts with the diminishing interest in the Windows API as a development platform. He then describes how two camps inside Microsoft (the "Raymond Chen" and the "MSDN Magazine" groups) are influencing Microsoft's approach to their developers' tools. The former group emphasizes creating a backward-compatible operating system, free of bugs and impervious to third-party applications' errors that can harm it. On the other hand is the MSDN group, promoting the latest and greatest Microsoft has to offer. As Spolsky sees it, the latter group has the upper hand, and because of this, Microsoft is losing their developer base to simpler, more easily deployed platforms.

In part 4 of the book, Spolsky takes on Microsoft's .NET strategy. He describes Microsoft's tendency to create FUD in the marketplace with vague, hollow statements, and details his own company's reasons for not adopting .NET anytime soon. Spolsky wraps up with a very straightforward feature request: a linker for .NET. This would seem to be an obvious feature, but Microsoft so far doesn't agree. Microsoft is acting as though they want to win the development platform war in a single sweep. At the same time, independent software vendors (ISVs) are resisting, because they have to guarantee backward compatibility and support for everything their customers run.

My only complaint about the book is that it's too short. On my bookshelf, it resides next to the Mythical Man Month, another favorite.

Spolsky is knowledgeable, funny and free of unnecessary religious fervor. Joel on Software is a must-read for developers, product managers and those who want more insight into the world of developing software.

Daniel Shefer is a Software Product Management professional and has written numerous articles on this topic. You can purchase Joel on Software from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Daniel Shefer writes "If you want to make money by selling your software, it has to be marketed, promoted and then sold to the customer. Doing this is not as easy as it may sound. The Product Marketing Handbook, 4th Edition details the ins and outs of the aspects of software product marketing needed to make this happen." According to Shefer, "this is a great book if you want to market your product and get it sold"; read on for the rest of his review. Even if your software is free (as in speech, or as in beer), this book may offer insights in persuading people to try it out. The Product Marketing Handbook, 4th Edition author Merrill R. Chapman pages 690 publisher Aegis Resources rating 9/10 reviewer Daniel Shefer ISBN 0967200865 summary A great guide to marketing, promoting and selling software.

Rick Chapman is also the author of In Search of Stupidity: Over Twenty Years of High-Tech Marketing Disasters (previously reviewed on Slashdot.) He is also the publisher and editor of Soft*Letter and the Software Success Newsletter. The Handbook presents today's best practices based on Chapman's extensive experience, and includes up-to-date information on everything from advertising to OEM agreements, pricing to visual identity.

The book offers practical insights into vexing product marketing-problems. Throughout the book, Chapman gives relevant, down-to-earth descriptions of how to (and how not to) plan and deliver product-marketing efforts. There are case studies from every aspect of the high-tech industry, as well as detailed lists of dos and don'ts.

This is a great, safe place to learn about marketing, distributing and selling software before putting your own time and money at risk; the Handbook includes comprehensive checklists to help manage the product-marketing process. (These lists are also provided on a CD that accompanies the book.)

The text starts with an overview of some changes the software market has seen since the book's first edition. Chapman focuses on one of the most significant changes since then and discusses the rise of open source computing and Linux. He then continues to the book's raison d'être with a brief discussion of why software companies fail.

The first chapter covers market research. Before spending resources on writing code, it is always best to know if there is a real need for the product, and what other companies are up to in the intended market space. The chapter starts with an overview of several research techniques such as conjoint analysis, focus groups and competitive intelligence.

The next chapter discusses some of the hardest issues in marketing software: positioning, pricing and naming. A great example, the OS/2 debacle is a classic study in how not to name or position a product.

These chapters detail how to position a product, how to brand it, and how to price it so both you and your sales channels can make money off of it.

Chapter 3 discusses channel distribution. Channels are the organizations that move a product to the customer. First, you have to decide if you will provide the product as an ASP or shrink wrapped. In the latter case, selling the software requires a logistics backbone that small independent software vendors (ISVs) may not be able to afford. While some software packages can be successfully sold using online channels exclusively, these are the exceptions. Other ISVs have to utilize distributors, VARs, store chains and catalogs to move their products. Getting these channels to distribute the product is not as easy as sending them a copy and expecting them to "see the light." It takes a good understanding of the channels' business models and capabilities (as well as hard work on your part) to get to the point where a customer sees your product in a CompUSA or a printed catalog. Channels have to be located, contacted, convinced, trained and constantly supported to make this happen. This chapter also covers OEM and international distribution issues.

The next chapters discuss collateral advertising (brochures, white papers etc.), PR, advertising and sales promotions respectively. While none of these are rocket science, getting them wrong is a costly proposition. In addition to the effort involved and their cost, there are legal implications as well. For example, not properly estimating the return rate of a rebate coupon or making an inaccurate claim in a piece of collateral can land a company in hot water. Most ISVs outsource these activities to experts, but even doing that successfully requires at least a general understanding of these topics.

Chapter 8 discusses direct marketing. Some of the topics covered in this chapter are direct mailings, infomercials, telemarketing, mailing lists and fulfillment.

Chapter 9 covers software bundling. Bundling is where companies offer two or more products as a bundle. You're almostly certainly familiar with this from the way companies like Amazon offer two related products for a slightly better price then their combined prices. How and why to bundle are explained in this chapter.

Chapter 10 discusses the topics Internet marketing. In theory, the easiest way to market a product these days is over the web. One creates a website, submits it to Google and Overture (Yahoo!), and presto, there are visitors who buy the product. It's not so simple,though: The problem is luring potential customers to the website, keeping them there, and leading them to purchase the product. This chapter covers designing and optimizing websites as well as managing discussion groups, list servers and online ad campaigns. Another important topic is search engine optimization (in simple English, getting your website to the top of the Google and Overture Results pages). The text includes many dos and don'ts on how this is done.

Chapter 11 discusses trade shows. I don't think highly of tradeshows (see the rightful demise of Comdex) but if you decide to go down this road, here's how to do it properly.

Chapter 12 discusses sales methodologies and strategies. It opens with the trick question that most people get wrong: What is the number one reason that software companies fail? The correct answer, of course, is "not enough sales."

There are inherent reasons that you are a developer writing code or a sales rep doing sales. There are the basic character traits that make each of you good at what you do. I'm not saying that as a developer you can't sell. You may be able to -- but probably not as well as a seasoned sales rep. As with other issues, you will need to understand the dynamics of the sales process so you can create a product that makes it easier to sell. This chapter will introduce you to basic concepts such as the pipeline, prospecting and, the software selling cycle. It will also take you through the multiple steps of complex sales cycles which are a painful part of selling large systems. But, as bank-robber Willie Sutton supposedly said, that's where the money is. No less important is the discussion of negotiation and presentation techniques.

The last chapter in the book gives a brief overview of product management and the processes involved. While relevant and accurate, I would defer to other texts on the subject for a more thorough discussion of product management. See, for instance, Software Product Management Essentials by Alyssa S. Dver, or The Product Manager's Handbook by Linda Gorchels.

The book includes three appendices: A product marketing cost matrix, a product marketing resource directory and a product marketing timeline, and ends with a glossary and index. Attached to the book is a CD which includes all the checklists that are dispersed throughout the book as well as several sample files.

The Handbook's depth and breadth as well as the author's experience make it the best book on product marketing I've encountered.

Reviewer Daniel Shefer is a Software Product Management expert and has written numerous articles on this topic. The Product Marketing Handbook, 4th Edition is available only through the author's website. For more about product marketing see: www.ProductMarketing. com.

Slashback is back from a Thanksgiving hiatus with a bigger-than-usual collection of updates, corrections and followups to previous Slashdot stories, including pretty maps of the Internet, spammers' OS choices, stupidity in the wild, and more. Read on for the details. Of course, Red Hat didn't claim to be the first ... cmeyer writes in response to the news that Red Hat is expected to attain Common Criteria certification. "Linux achieved the first Common Criteria certification back in the beginning of August. It was a joint effort of IBM and SUSE." He points to this August Slashdot posting about the news and to a press release on SUSE's site.

Well, it's robust, stable and handy for networking tasks ... Linux and Unix users may be justifiably smug about our machines' resistance to viruses and trogans (including ones that send spam), since most of these things are aimed at Microsoft Windows. Maybe it should be no surprise that spammers like Linux, too:

Niels Provos writes "You might remember Honeyd? I have been using it since June to capture spam emails in an attempt to better understand how spammers operate. A recent feature in Honeyd is passive fingerprinting which allows Honeyd to passively identify the operating system that contacts it. For spammers, it turns out that about 43% seem to be running Linux. And mostly Unix, Windows ranks at around 0.7%. The unknown fraction is 52%, so there might be surprises lurking there."

Apple products must be ripened before consumption. Ipodlounge.com editor Dennis Lloyd was one of several readers to note that, rather than the November date named in the recent 2-year iPod retrospective in the New York Times, the device came out just a bit earlier. "The iPod's anniversary was in October ;) The iPod was officially launched on Oct. 23, 2001. The NYT article is incorrect."

May the tide be with you. Doc Searls writes: "Thought I'd direct your attention to the first half of a transcription of the talk Linus gave on the September Geek Cruise that got Slashdotted a few weeks ago. Can't find the link to the Slashdot item, but as i recall it didn't have the benefit of a real transcription." (Here's the Slashdot post about the cruise.) "This one is not only a full transcription (by yours truly, all disclaimers apply), but features pix of his slides and demos as well."

Searls also has up the second part: "That's the Q&A, which is even longer than the prepared part of the talk," as well as the third: "The third part is a transcription of a talk Linus and others gave to the Victoria Linux Users Group. Shorter than the first two."

Searls' three-part report on the cruise itself ran in Linux Journal.

This way to the Egress! Rick Chapman, author of the recently reviewed In Search of Stupidity , writes to point out that book excerpts are available at insearchofstupdity.com, along with some of the book's illustrations.

"Also, I recently was interviewed live on a local CT business show and I've had the session digitized and am mounting on the site today. It runs about 45 minutes and I discuss a lot of the stuff in the book as well as other issues revolving around software marketing and development. ... I have a lot of samples of really bad things I brought to the taping and I think you'll get a kick out of the session."

They should sell nice prints to buy bandwidth. An anonymous reader writes "From the New Scientist article: A project to create a comprehensive graphical representation of the Internet in just one day and using only a single computer has already produced some eye-catching images."

Back pedal, back pedal, baker's man, cover that label with tape if you can. Mr. Slippery writes "According to this Yahoo! News story, L.A. County did not ban the use of 'master' and 'slave' in labeling, but made more of a polite request to vendors. A subtle but important distinction.

'"I do understand that this term has been an industry standard for years and years and this is nothing more than a plea to vendors to see what they can do," said Joe Sandoval, division manager of purchasing and contract services. "It appears that some folks have taken this a little too literally."' (As, perhaps, did those who got offended in the first place...)"

The original memo called Master and Slave labels "not acceptable" -- how non-literally can that be taken? -- and as further news stories have reported, was prompted by an employee's workplace discrimination complaint against the city. That sounds to me like more than a polite request. At least the city has found that a little tape is enough to make the world safe from misinterpreted words.

I bet Bill is a better actor than Keanu. Karma Sucks writes "After some embarrassing PR backlash it seems as if Microsoft is clamping down on distribution of pictures or videos related to the Matrix Spoof that featured Linux and Windows at COMDEX. Even more interesting are the reports that Microsoft is systematically scouting Open Source desktop technology."

And this is what percentage of the industry's profits? dlh writes "Boston.com is reporting that a federal judge Thursday approved a $143 million settlement of a lawsuit that accused major record companies and large music retailers of conspiring to set minimum music prices."

Time to get a new watch. Krellis writes "DynDNS.org, a major dynamic DNS provider, has announced that they will shut off access to any customers using the Linksys WRT54G wireless router to update their service on December 8th unless the router is patched. See the story on ExtremeTech and the DynDNS Press Release for more details. Updated firmware can be downloaded from Linksys."

Alex Moskalyuk writes "There are dozens of titles on 'corporate excellence.' Management types like them. They teach the best practices from known companies and let you know how ABC Inc. or XYZ Corp. became such a glorious business as it is. In Search of Excellence (ISBN: 0446385077) is one of them, deserving the title of 'management bible' from its publishers. Apart from the minor detail that some of the data in the book was faked. At times like these, where do you turn for a good management advice?" Read on for Alex's review of an alternative text, Merrill R. Chapman's In Search of Stupidity. In Search of Stupidity: Over 20 Years of High-Tech Marketing Disasters author Merrill R. Chapman pages 256 publisher APress rating 10 reviewer Alex Moskalyuk ISBN 1590591046 summary Over 20 Years of High-Tech Marketing Disasters

Rick Chapman, on the back of the dustcover, features an impressive resume of MicroPro, Ashton-Tate, IBM, Inso, Microsoft, Novell, DataEase, Stromberg, Sun Microsystems, Teradata and Ziff-Davis. For those who just recently caught up to speed with the computer industry, some names might sound unfamiliar. Indeed, a great many tech companies were driven into the ground either by poor management practice or poor product planning.

About the book

The author explores the stories of Digital Research, MicroPro, Ashton-Tate, Borland, Motorola, Novell, Netscape and a slew of ASPs (Application Service Companies), as well as dot-coms, to derive lessons on mismanagement. Chapman also talks about current behemoths, IBM, Intel and Microsoft, telling stories of numerous product failures and the ways the companies have managed to deal with each blow. Apple Computer is also mentioned, but don't forward a copy of the title to your local friendly Mac zealot -- contemplating Apple's current market share and influence on the market (with some speculations on what could have been done), Chapman calls Apple the world's largest irrelevant company.

Want to learn secret skills of ruining a perfectly good product line? How about being a great company for thousands of developers and then pissing off almost 100 percent of them? Want to get a clear roadway on publishing two parallel software products that compete with one another, while even the sales people are unable to clarify the differences? In Search of Stupidity takes the reader on the joyous ride, following closely the growth and downfall of technological giants.

Developers! Developers! Developers!

Famous Joel Spolsky provided a preface for Chapman's title, where he provided some interesting statistics about world's largest consumer software companies as well as thoughts on the issue of who runs the company better -- programmers or business majors? "When Pepsi-pusher John Sculley was developing the Apple Newton, he didn't know something that every computer science major in the country knows: handwriting recognition is not possible. This was at the same time that Bill Gates was hauling programmers into meetings begging them to create a single rich text edit control that could be reused in all their products," writes Spolsky, implying that people who run software or hardware companies better have some knowledge about their business.

Chapman's critique of that preface runs throughout the book -- the famous setback that can be expected from the developer's community is the notion that the code should be re-written for the new version, as the old one simply is too buggy and it's easier to start anew.

What's good about the book

In the introduction chapter Chapman provides a great overview of what to expect in the book. His style is lively, full of analogies and old tales. The book is marked by a good sense of humor, without actually going into jokes (except for occasional re-telling of Intel Pentium FPU-related humor). All the companies who were not big enough to deserve a separate chapter but still stupid enough to be in the book are mentioned in introduction. Street Technologies, who in an advertising brochure bravely claimed the owner of its software could "eliminate half of the work force," and whose literature probably never made it through the mail room. Syncronys, who sold the SoftRAM product, which promised to "double your computer memory," except for the fact it didn't actually do it. Project Iridium from Motorola, which burned through $5 billion before figuring out that market for thousand-dollar phones and hundred-dollar service charges was a bit limited.

The table of contents can be found on the book Web site, and from the subchapter names like "The Great Pentium Bunny Roast" one can deduct that the book is full of good humor mixed with sarcasm. Sometimes Chapman is merciless when mentioning some of his stories' subjects. Here's his introduction to a chapter on Netscape vs. Microsoft battle:

If you like the horror movies, you know the cast usually sports a character you've come to think of as The Idiot Who Deserves to Die. He's the knucklehead who runs screaming into the path of Godzilla just as the giant reptile is heading out to spend a relaxing afternoon destroying Tokyo, and gets squashed like a bug. The dimwit who sticks his noggin out of the deserted cabin in the woods and yells out "Mad slasher? What mad slasher?" just before the mad slasher decapitates him. The space-bound fumble-fingers who always manages to drop his blaster right when the Tentacle of Doom is zeroing it on him for lunch. If Marc Andreessen, co-founder of one-time wonder company Netscape, ever gives up high tech for a career in horror movies, he'll play that character.

The author does provide a pretty good collection of facts on just what Netscape has done wrong, and how Microsoft's onslaught could have been avoided, so the quoted paragraph is not just an attempt to personally insult Andreessen. Here's a story of Ashton-Tate and its leader Ed Esber, who eventually ruined the company:

Esber did fancy himself something of a business guru, and one of his favorite quotes was "A computer will not make a good manager out of a bad manager. It makes a good manager faster and a bad manager worse faster." He had something there. It had taken George Tate about 5 years to build Ashton-Tate to software giant status; it would take Ed Esber only 2.5 years to put the company on the road to ruin. And Esber had a PC on his desk the entire time.

Debunking the myths

Besides providing a lot of good stories from the history, Chapman also tries to dispell some myths about the industry. Most of the myths somehow involve Microsoft, which is hardly surprising, provided Chapman dedicated more attention to software companies than hardware companies. He describes the attitude towards the company in the early stages of the industry development, points out why ISVs flocked towards DOS/Windows instead of more stable OS/2, and denies the common belief that Bill Gates' project owes most of its success to the deal with IBM to put DOS on the PC.

Chapman also analyzes the mistakes made, and shows how Apple Computer could've been the 99% market share vendor right now, but a few stupid mistakes in the company's past allowed for better short-term gains while leading the company into oblivion. In the last chapter, the demise of dot-coms and application service providers is told in a sort of haphazard way, without going into details of any specific company. Chapman keeps his sense of humor and is not so full of sarcasm and "I told you so" attitude as Philip Kaplan's F'd Companies .

Overall

The book is an enjoyable read, and with roughly 250 pages of interesting and fact-packed text makes an informative one, too. Even if you have been in the industry long enough to know better about the mistakes Chapman names, the book is worth reading just to re-fresh the past memories and learn some juicy details about the companies' internals (Chapman personally worked in MicroPro's WordStar team and at Ashton-Tate, among others). For others, it's a great learn to take a look at serious and less-serious screw-ups by major technological companies.

Each chapter is preceded by a caricature. The chapter on MicroPro shows WordStar and WordStar 2000 pointing a gun to one another's head with an apparent attempt to pull the trigger. The chapter on OS/2 (titled The Idiot Piper) shows that very idiot piper playing apparently a tune of OS/2, while the products designed for the operating system are heading off the cliff. Chapter on Intel's Pentium flop features bunny suits dancing around the barbecue fire with equations like "9/3 = 2.999" on their aprons.

In Search of Stupidity is an excellent source of information, analysis and good laughs. It's one of the few industry titles that will give you a large supply of stories to re-tell to other developers over a beer. Chapman's book is also an excellent case study collection of anti-management rules that one should avoid when running a high tech company.

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