Slashdot Mirror

A new take on the age-old question: Should you rewrite your application from scratch, or is that "the single worst strategic mistake that any software company can make"? Turns out there are more than two options for dealing with a mature codebase. Herb Caudill: Almost two decades ago, Joel Spolsky excoriated Netscape for rewriting their codebase in his landmark essay Things You Should Never Do . He concluded that a functioning application should never, ever be rewritten from the ground up. His argument turned on two points: The crufty-looking parts of the application's codebase often embed hard-earned knowledge about corner cases and weird bugs. A rewrite is a lengthy undertaking that keeps you from improving on your existing product, during which time the competition is gaining on you.

For many, Joel's conclusion became an article of faith; I know it had a big effect on my thinking at the time. In the following years, I read a few contrarian takes arguing that, under certain circumstances, it made a lot of sense to rewrite from scratch. For example: Sometimes the legacy codebase really is messed up beyond repair, such that even simple changes require a cascade of changes to other parts of the code. The original technology choices might be preventing you from making necessary improvements. Or, the original technology might be obsolete, making it hard (or expensive) to recruit quality developers.

The correct answer, of course, is that it depends a lot on the circumstances. Yes, sometimes it makes more sense to gradually refactor your legacy code. And yes, sometimes it makes sense to throw it all out and start over. But those aren't the only choices. Let's take a quick look at six stories, and see what lessons we can draw.

Thornburg contributes news of a story spotted on Techmeme, writing: "[Joel Spolsky of] Joel On Software has a story about how he found and submitted prior art for a Microsoft patent listed on Ask Patents in 15 minutes. The patent was rejected based largely on the document he submitted." Spolsky gives a very readable introduction to the patent system, and software patents in particular; I especially like this part: "Software patent applications are of uniformly poor quality. They are remarkably easy to find prior art for. Ask Patents can be used to block them with very little work. And this kind of individual destruction of one software patent application at a time might start to make a dent in the mountain of bad patents getting granted. ... How cool would it be if Apple, Samsung, Oracle and Google got into a Mexican Standoff on Ask Patents? If each of those companies had three or four engineers dedicating a few hours every day to picking off their competitors’ applications, the number of granted patents to those companies would grind to a halt."

stephencrane writes "NYC is to open The Academy for Software Engineering, with a focus on software design and college preparation. It'll be a 'limited, unscreened' high school, which means admission won't be tied to grades or test scores; solely on interest (and presumably a lottery, once words gets out)." Would you want to go (or have gone) to such a school? Would you want your kids to attend?

theodp writes "I've been on teams that eat together every day,' writes Joel-on-Software Spolsky, 'and it's awesome. I've been on teams that don't, and lunch every day is, at best, lonely.' Spolsky is firmly in the camp that believes where and with whom we eat lunch is a much bigger deal than most people care to admit. 'There's a lot of stuff that's accidental about Fog Creek and Stack Exchange,' he concludes, 'but lunch is not one of them. Ten years ago Michael and I set out with the rather ambitious goal of making a great place to work. Eating together is a critical part of what it means to be human and what it means to have a humane workplace, and that's been a part of our values from day one.'"

An anonymous reader writes "In 2000, Joel Spolsky wrote the Joel Test, an excellent and simple way to evaluate a software company. While the test is still used, it's getting outdated, as many companies are moving to web technologies, and new development tools exist. In his blog, Marc Garcia wrote about what could be an update to Joel Test."

vlangber writes "Joel Spolsky wrote a famous blog post back in 2000 called 'Things You Should Never Do, Part I,' where he wrote the following: '[T]he single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.' Here is a story about a software company that decided to rewrite their application from scratch, and their experiences from that process."

-brazil- writes "Every programmer forum gets a steady stream of novice questions about numbers not 'adding up.' Apart from repetitive explanations, SOP is to link to a paper by David Goldberg which, while very thorough, is not very accessible for novices. To alleviate this, I wrote The Floating-Point Guide, as a floating-point equivalent to Joel Spolsky's excellent introduction to Unicode. In doing so, I learned quite a few things about the intricacies of the IEEE 754 standard, and just how difficult it is to compare floating-point numbers using an epsilon. If you find any errors or omissions, you can suggest corrections."

jafo writes "There's been a lot of teeth gnashing going on recently about broken wireless at conferences. We just wrapped up PyCon 2010, with around 600 (out of 1,000) attendees simultaneously accessing the volunteer-run network, and response has been fairly positive. 2.4GHz (802.11b/g) continues to be problematic, but most users were on 5.2GHz (using 802.11n) and associating at 130mbps, with a 100mbps link to the net (though after the fact we found that 35mbps would have sufficed). My PyCon 2010 wrap-up reveals all the secrets of how we did it, including pretty bandwidth and user graphs."

theodp writes "Newsweek's Daniel Lyons (that's Fake Steve to you) explains why Steve Ballmer is no Bill Gates, arguing that what most hurt Microsoft was BillG's decision to step down as CEO in January 2000: 'Gates was a software geek. He understood technology. Ballmer is a business guy.' And the problem with putting non-techies in charge of tech companies, concludes Lyons, is that they have blind spots. So while Microsoft's revenues nearly tripled from $23B to $58B on Ballmer's watch, says Lyons, the company became bureaucratic and lumbering, slowing down while the rest of the world — including Google, Apple and Amazon — sped up."

theodp writes "Joel Spolsky sings the praises of The Duct Tape Programmer, who delivers programming teams from the evil of 'architecture astronauts' who might otherwise derail a project with their faddish programming craziness. The say-no-to-over-engineering attitude of the Duct Tape Programmer stems not from orneriness, but from the realization that even a 50%-good solution that people actually have solves more problems and survives longer than a 99% solution that nobody has because it's in your lab where you're endlessly polishing the damn thing. Like Steve Jobs, Duct Tape Programmers firmly believe that Real Artists Ship."

guzzibill writes "Joel Spolsky has announced the beta release of Stack Overflow, intended to be a high-quality source of answers to software questions. Post a software question and watch the answers flow in. Popularity voting is very much woven into the site, where both questions and answers can be edited for clarity and voted up or down for correctness. Correctly posed questions and insightful answers float to the top. This site has reached critical mass." From Joel's description, he was envisioning a source of technical Q&A about programming. So far, many of the questions are broader and less technical, such as advice on the best book about software development. It will be interesting to see where the community that's forming takes it.

Microsoft has released documentation on their Office binary formats. Before jumping up and down gleefully, those working on related open source efforts, such as OpenOffice, might want to take a very close look at Microsoft's Open Specification Promise to see if it seems to cover those working on GPL software; some believe it doesn't. stm2 points us to some good advice from Joel Spolsky to programmers tempted to dig into the spec and create an Excel competitor over a weekend that reads and writes these formats: find an easier way. Joel provides some workarounds that render it possible to make use of these binary files. "[A] normal programmer would conclude that Office's binary file formats: are deliberately obfuscated; are the product of a demented Borg mind; were created by insanely bad programmers; and are impossible to read or create correctly. You'd be wrong on all four counts."

martincmartin asks: "The company I work for is starting to interview development managers, and I've been asked to interview a bunch of them. While there's been a lot written on interviewing programmers and what makes a good manager, how do you interview a management candidate? What questions do you ask? What are good and bad answers? What else do you do?"

guanxi writes ""As simple as possible, and no simpler", you might have heard a few time, or KISS (Keep It Simple Stupid). No more! The new hot trend is complexity: '[I]f you think simplicity means ... "does one thing and does it well," then I applaud your integrity but you can't go that far' says Joel Spolsky. 'Why are Yahoo! and MSN such complex-looking places? Because their systems are easier to use [than Google]' explains Donald Norman, who also also tells us that Simplicity Is Highly Overrated. Are they trying to make a subtler point, are they just consultants making a splash, or complexity the Next Big Thing in design?" From the 'highly overrated' article: "After touring the store my two friendly guides and I stopped outside to where two new automobiles were on display: two brand new Korean SUVs. Complexity again. I'm old enough to remember when a steering wheel was just a steering wheel, the rear view mirror just a mirror. These steering wheels were also complex control structures with multiple buttons and controls including two sets of loudness controls, one for music and one for the telephone (and I'm not even mentioning the multiple stalks on the steering column). The rear view mirror had two controls, one to illuminate the compass the other simply labeled "mirror," which lit a small red light when depressed. A rear view mirror with an on-off switch? The salesperson didn't know what it did either."

twofish writes, "Following on from Joel Spolsky's blog on the Windows Vista shutdown menu, Moishe Lettvin, a former member of the Windows Vista team (now at Google) who spent a year working on the menu, gives an insight into the process, and some indication as to what the approximately 24 people who worked on the shutdown menu actually did. Joel has responded in typically forthright fashion." From the last posting: "Every piece of evidence I've heard from developers inside Microsoft supports my theory that the company has become completely tangled up in bureaucracy, layers of management, meetings ad infinitum, and overstaffing. The only way Microsoft has managed to hire so many people has been by lowering their hiring standards significantly. In the early nineties Microsoft looked at IBM, especially the bloated OS/2 team, as a case study of what not to do; somehow in the fifteen year period from 1991–2006 they became the bloated monster that takes five years to ship an incoherent upgrade to their flagship product."

twofish writes, "Following on from Joel Spolsky's blog on the Windows Vista shutdown menu, Moishe Lettvin, a former member of the Windows Vista team (now at Google) who spent a year working on the menu, gives an insight into the process, and some indication as to what the approximately 24 people who worked on the shutdown menu actually did. Joel has responded in typically forthright fashion." From the last posting: "Every piece of evidence I've heard from developers inside Microsoft supports my theory that the company has become completely tangled up in bureaucracy, layers of management, meetings ad infinitum, and overstaffing. The only way Microsoft has managed to hire so many people has been by lowering their hiring standards significantly. In the early nineties Microsoft looked at IBM, especially the bloated OS/2 team, as a case study of what not to do; somehow in the fifteen year period from 1991–2006 they became the bloated monster that takes five years to ship an incoherent upgrade to their flagship product."

wikinerd writes "How can we get rid of the widely hated cubicle and its ugly cousin, the stressing open-plan office? Some business owners and managers cannot understand the advantages of teleworking, different office layouts, or the morale benefits of private offices with Aeron chairs. There are still people in high positions who seem to think that stuffing a bunch of engineers into a noisy landscaped office is the best way to organize a company. It is not, and we all know it, but can we prove it? How can we communicate to them the fact that living in a groundhog warren is bad not only for the engineers, but also for the organization?"

A. Bosch writes to mention that Joel Spolsky of Fog Creek software has a commentary that examines the need for choices in software. From the article: "This highlights a style of software design shared by Microsoft and the open source movement, in both cases driven by a desire for consensus and for 'Making Everybody Happy,' but it's based on the misconceived notion that lots of choices make people happy, which we really need to rethink." With software steadily becoming more sophisticated, are more choices really necessarily better?

JoelonSoftware's most recent piece is about some of the fallacies in "Agile" software and some of the issues within it. We use Agile in some parts of the company, and have had success with that -- that said, there's always the peril that happens when development and other parts of the company have...miscommunication, which sounds like the problem described in Joel's piece.

Raindance writes "Joel on Software has an interesting piece on why Big Content is making loud noises about moving from 'flat fee' to 'tiered' pricing models on the iTMS. According to Joel, it's not about pricing songs commensurate with their economic value; rather, it's about allowing the labels to manipulate public perception of value through pricing." From the article: "And now when a musician gets uppity, all the recording industry has to do is threaten to release their next single straight into the $0.99 category, which will kill it dead no matter how good it is. And suddenly the music industry has a lot more leverage over their artists in negotiations: the kind of leverage they are used to having. Their favorite kind of leverage. The "we won't promote your music if you don't let us put rootkits on your CDs" kind of leverage."

meryl (Meryl K. Evans) writes "Having been in process management in a software organization for over ten years, I've seen too many articles and books on the topic that worked better than Valium for putting me to sleep especially since they have no side effects. You know that Joel Spolsky is one of the best writers on the topic of software. However, in this book he stands aside and lets others demonstrate that he isn't the only one who can write about software in English and captivate you." Read on for Evans' review. Best Software Writing I: Selected and Introduced by Joel Spolsky author Joel Spolsky, editor pages 328 publisher Apress rating 8 reviewer Meryl K. Evans ISBN 1590595009 summary 29 essays by multiple authors covering a range of development-related topics. Joel on Software fans won't be disappointed in the selection of authors as they deal with the concepts Spolsky writes about on his site. Some readers may be expecting a book solely on software development. Even Joel goes beyond this. Some folks might be disappointed that most of the articles, blog entries, speeches, and essays are available somewhere on the Web. I only recognize a few of the authors and their articles, though, so I would've never known about the others had I not found this book.

The essays cover a wide range of development-related topics. They include coding style, outsourcing programmers, dealing with Excel as a database (gag, gag), using social software (and the things that are right and wrong with these shared spaces), emerging digital rights, and defining the two-phase commit process a la Starbucks. A few of them are nothing but comics. The one on Windows search will knocks readers out of their chairs laughing, at least it did me.

The book also contains business-related essays that address a few problems affecting many companies -- namely team compensation and forced overtime which often spills over the weekend. Joel introduces every essay and includes notes clarifying abbreviations, names, or terms that you most likely know. But other people who would benefit from the book may not -- cut Joel some slack for providing these notes.

The manager benefits from the book because she gains insight into the developer's perspective, which could help her become a better leader. The developer benefits because many of the issues covered can affect him no matter what language he uses for development. If you belong to neither management nor development, the best way to decide if the book is for you or not is to review the table of contents and reviews. If you find only one or two interesting possibilities, search for them online instead.

I'm one of those who belong to neither group. My software organization background has been along the lines of an analyst and process manager. Even I find that most of the essays are enjoyable or educational. Only one or two lost me.

While most of the content is available on the Internet for free and all of you can find it, the book is worth the bucks. It's nice having a collection of high-quality writing related to software and the business in one place instead of trawling the Web for it. Furthermore, you get an opportunity to read offline -- if you manage to tear yourself away from the monitor every now and then at least; I read most of the book while traveling on an airplane. The flight flew by, thanks to the book. I appreciated and absorbed the essays better by reading them in the book than I would have had I read them online.

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

loquacious d asks: "This has been a spectacular summer for open-source student internships. Google funded a huge variety of open-source projects through the Summer of Code, including GCC-CIL and other improvements to Mono, new features and fixes for Gaim, and even new packages for Common Lisp. Joel Spolsky at Fog Creek hired four interns to produce a highly modified version of VNC called Fog Creek Copilot, and Paul Graham's new venture capital firm Y Combinator helped students create their own tech companies. What internships did people enjoy this summer, and which ones didn't work out so well? Which ones would you recommend to next year's applicants, and which should they avoid?"

Doctor O writes "Joel Spolsky (of joelonsoftware fame) has some good points and fun with numbers on the quality of programmers and whether it is more profitable to go with cheap or good programmers. His point is that a good programmer will simply create code of a quality that average programmers never can create. An interesting read."

Doctor O writes "Joel Spolsky (of joelonsoftware fame) has some good points and fun with numbers on the quality of programmers and whether it is more profitable to go with cheap or good programmers. His point is that a good programmer will simply create code of a quality that average programmers never can create. An interesting read."

An anonymous reader asks: "A couple years ago Joel Spolsky wrote an interesting critique of Eric S. Raymond's The Art of Unix Programming wherein Joel provides an interesting (as usual) discussion on the cultural differences between Windows and Unix programmers. As a *nix nerd in my fifth year managing mainframe developers, I need some insight into mainframe programmers. What are the differences between Windows, Unix, and mainframe programmers? What do we all need to know to get along in each other's worlds?"

An anonymous reader asks: "A couple years ago Joel Spolsky wrote an interesting critique of Eric S. Raymond's The Art of Unix Programming wherein Joel provides an interesting (as usual) discussion on the cultural differences between Windows and Unix programmers. As a *nix nerd in my fifth year managing mainframe developers, I need some insight into mainframe programmers. What are the differences between Windows, Unix, and mainframe programmers? What do we all need to know to get along in each other's worlds?"

xeon4life asks: "I'm an Austin, Texas area high school senior with a slight dilemma: I need a job, I don't want what's offered at my age, and internships are not quite open for kids like me. I've recently been reading essays by Paul Graham about creating your own startup and have been motivated enough to convince two of my good friends to go into business with me later, during college. Thus, an internship at this point would be the ideal solution for me now, but nobody is willing to take me as an intern because I'm still in high school. What am I to do?" "People have suggested that I just do what every other good American high school citizen does and take a mediocre job. The problem is, I feel it would be a waste of my talents right now to be stuck folding shirts at the local mall or flipping cheeseburgers when I could be helping develop a cutting-edge game, the next-generation compiler, or even the Linux kernel as an intern. I have a higher than most college students' understanding of concepts, and some real programming experience in languages like assembly and C/C++, but that isn't going to amount to anything if I can never find an interviewer who will at least listen to me. I'd appreciate any input the Slashdot readership can give me."

An anonymous reader writes "Joel on Software explains what college students should do with their lives. Interesting to note is how he justifies such trivialties as GPA scores and well-roundedness, the very things comments here tend to think are overrated. In short, learn to write English, learn to write C, and don't worry about India!"

An anonymous reader writes "Joel on Software explains what college students should do with their lives. Interesting to note is how he justifies such trivialties as GPA scores and well-roundedness, the very things comments here tend to think are overrated. In short, learn to write English, learn to write C, and don't worry about India!"

prostoalex writes "No one quite knows the exact point when high-tech marketing went wrong. When instead of selling distinct products and services, the company Web sites and brochures started pitching 'the next big thing.' When even software developers don't have a slightest idea about what's being sold to them. Raj Karamchedu from Silicon Image, however, feels that certain things in high-tech marketing should be straightened out, hence this book." Read on for Moskalyuk's review of Karamchedu's It's Not About the Technology . It's not about the technology author Raj Karamchedu pages 230 publisher Springer rating 4 reviewer Alex Moskalyuk ISBN 0387233504 summary Developing the craft of thinking for a high-tech corporation

20 chapters are written from the point of view of tech marketing executive, as Karamchedu tries to answer the question of why some products gain a loyal audience and enjoy commercial success, while the others are simply additions to the dusty shelves of history. Everyone has their favorite comparison, where a technically advanced product does not gain acceptance on the market while a supposedly inferior competitor is rolling in cash. Hey, IBM built an entire theory on how it was safe to let Microsoft sell its not-so-great DOS with IBM PCs in order to push the hardware from the warehouse while the company was preparing the next revision of state-of-the-art OS/2 -- which, of course, everyone will buy on the day of release in order to replace Microsoft's software.

History occasionally teaches tech marketers some curious lessons, and the conclusion that the author comes up is summarized in the book title. The title might sound like an insult to a design engineer, but in most of the cases the success in the market is not guaranteed by superiority of technology. Karamchedu is on the mission to find out why.

The first chapters take us through a conflict inside a company. Seldom will you find a high-tech startup where marketing people do not clash with engineers. Marketers promise the features to the customers in order to adhere to the mantra of "we listen to our customers," only to see feature requests denied by the engineers, since the budgets and deadlines are fixed. Marketers then complain to the executives about lack of response from the engineering staff and their inability to deal with the new features, while engineers fight back, claiming that the product is about to miss the deadline even with existing feature set and overworked staff.

Later, Karamchedu focuses on a second problem, peculiar to high-tech marketers: after being immersed in the technology world for too long, they cannot relate to the customers. Hence grandmas in Best Buy staring at the computer described as "P4 3.0 GHz 256 DDR 40.0 GB DVD/CD-RW" when all she wants to know is whether she can check email and view photos of the grandkids. Marketers forget to empathize with the customers. They spend too much time with engineering, and like to tell customers how the new microprocessor has a much wider front-side bus, or how their new piece of software supports dual-core systems, without really telling the customer how that will improve business processes or increase efficiency.

The third part of the book takes a look at a typical semiconductor company and tries to draw the plan of attack for a starting marketing executive. At this point the book turns into a manual on high-tech marketing, which the author hopes the readers will find useful, as there are no set rules and algorithms for launching successful marketing campaigns in high-tech world.

The book is quite insightful, but one can't help but feel that it is missing something. It will probably prove to be a valuable read to anyone facing the daunting task of marketing a high-tech product, but even though I got to the last page of the book, I found the title to be too terse and dry, lacking concrete examples and not quite coherent as far as the chapter-by-chapter arrangement. The preface and the author's description of the book are available online. It's also strange that in an attempt to write a textbook on high-tech marketing, the author decided to provide no case studies whatsoever. In Search of Stupidity from Apress is a great book about high-tech marketing, since it tells the story of a failed marketing attempt and also tries to figure out the reasons, but in It's Not About the Technology, Karamchedu just tells years of his personal experience, without references to specific companies or projects, which makes the book a compilation of abstractions on high-tech marketing.

In his spare time Alex enjoys reading technology and business titles. He also keeps a collection of free books for readers on a budget." Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

sammykrupa writes "Google suggest Javascript code dissected and rewritten for all of you web developers out there. Cool piece of web reverse-engineering!" Joel Spolsky astutely notes that this will raise the bar in terms of how people expect the "internets" to work.

Jaero writes "The Spouse has a followup post to her "EA: The Human Story" from over a month ago. Not only was it nominated for a Best Software Essay of 2004, but she has revealed plans to start an independent industry watchdog organization called GameWatch.org, meant to monitor the quality of life in the game development world. Anyone will be able to post their story, as well as design the logo (a contest which lasts until January 15th)."

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.

AceMarkE writes "Joel Spolsky of Joel on Software has posted an article entitled "How Microsoft Lost the API War". He covers why the Win32 API is important to Microsoft, what they've done to keep it working, why Microsoft's switch to the .Net platform is both a good and bad idea, and why he feels the browser will be the real future of application development. Definitely worth a read no matter what your opinion of Microsoft is."

AceMarkE writes "Joel Spolsky of Joel on Software has posted an article entitled "How Microsoft Lost the API War". He covers why the Win32 API is important to Microsoft, what they've done to keep it working, why Microsoft's switch to the .Net platform is both a good and bad idea, and why he feels the browser will be the real future of application development. Definitely worth a read no matter what your opinion of Microsoft is."

Not-to-desperate asks: "There is lots of info around on interviewing when hiring but what about the other way around? What do you look for in an employer? Are the any 'minimum requirements' that should be met? Obviously if you haven't got a job at all, getting hired is the main criteria, but what if you're jumping ship so to speak? I'm thinking of stuff like better salary, work conditions, type of projects, possibility of on the job training, and so on."

CrypticSpawn asks: "I read an article on Joel on Software it talks about Microsoft missing one important thing from the .NET infrastructure, and I wanted to know what Slashdot readers thought were Microsoft's reasons for leaving [a linker] out?"

rbrandis writes "Mr. Spolsky's latest rant is about writing a resume that will be read "Please do not use cover letters that you copied out of a book. If you write 'I understand the position also requires a candidate who is team- and detail-oriented, works well under pressure, and is able to deal with people in departments throughout the firm' then at best people will think you're a bullshit artist and at worst they will think that you were not born with the part of the brain that allows you to form your own thoughts and ideas.""

bebonzo writes "Joel Spolsky, 'Joel on Software' has an interesting review of Eric S. Raymond's book about 'The Art of UNIX programming'. Quote:"What are the cultural differences between Unix and Windows programmers? There are many details and subtleties, but for the most part it comes down to one thing: Unix culture values code which is useful to other programmers, while Windows culture values code which is useful to non-programmers." About slashdot: "slashdot-karma-whoring sectarianism..."" He's harsh on some points, but pretty on the money. Except about us. Nobody karma whores. Update Note to self, never post before coffee. Yes, its a dupe. get over it.

bebonzo writes "Joel Spolsky, 'Joel on Software' has an interesting review of Eric S. Raymond's book about 'The Art of UNIX programming'. Quote:"What are the cultural differences between Unix and Windows programmers? There are many details and subtleties, but for the most part it comes down to one thing: Unix culture values code which is useful to other programmers, while Windows culture values code which is useful to non-programmers." About slashdot: "slashdot-karma-whoring sectarianism..."" He's harsh on some points, but pretty on the money. Except about us. Nobody karma whores. Update Note to self, never post before coffee. Yes, its a dupe. get over it.

giampy writes "Joel Spolsky writes a review-like article on the last book of Eric S. Raymond (The Art of Unix Programming). His views on the cultural differences among Windows and Unix programmers are well explained. Overall, an interesting read." Also on the topic of Windows, badriram writes "Microsoft is reorganizing the windows team, it seems the are separating the OS core development. Seems like things heading in the right direction in creating a more secure OS, and making it more business oriented. Read the article here."

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.

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.

hondo77 writes "Joel Spolsky has finally moved Fog Creek Software into their new digs. Read about what went into the design of "the ultimate software development environment" from your (my) cube and drool."

hondo77 writes "Joel Spolsky has finally moved Fog Creek Software into their new digs. Read about what went into the design of "the ultimate software development environment" from your (my) cube and drool."

Evil Grinn writes "In Building Communities with Software, Joel Spolsky starts with a lament about the lack of real-life community among programmers, but rapidly seques into an explanation of why he thinks his own forum system is better than Usenet or Slashdot. I really don't participate in Joel's forums enough to comment, but they are pretty basic. No registration system. No branching (you can only add comments to the end of a conversation, not reply to comments in the middle). No mod points. Quoting in replies is strongly discouraged. All of these are part of the design of the system, not missing features."

WeNeedBetterTools asks: "Help! I am trying to convince the leaders of my development organization that the quality of our bugtracking tool has a meaningful impact on the quality of products we produce. Right now, the tool we have is difficult to use because there is a high overhead to creating bugs, and they are very difficult to find in the system once they're reported. My main argument is that the easier the tool is to use, the more people will be motivated to enter bugs. My managers argue that if people aren't entering bugs, it's their own damn problem, and we ought to crack the whip until they always file every bug they possibly can. I need some solid references for my position. JoelOnSoftware has a great argument for making it simple to enter bugs, but he lacks credibility with my managers by virtue of the fact that he is also selling a bugtracking tool. Can anyone point me to any solid research on the relationship between the quality of bugtracking tool and the impact on product quality?"

Joel Spolsky has a nice essay on the leaky abstractions which underlie all high-level programming. Good reading, even for non-programmers.

Stephen writes "The ever-incisive Joel Spolsky discusses the economics of open source software in his latest Joel on Software column. Why do so many large companies want to develop open source software? It's not because they have suddenly converted to Stallmanism."

Stephen writes "The ever-incisive Joel Spolsky discusses the economics of open source software in his latest Joel on Software column. Why do so many large companies want to develop open source software? It's not because they have suddenly converted to Stallmanism."