Slashdot Mirror
In Search of Stupidity
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.
are stupid people ever aware that they're behaving stupidly?
The answer is "usually not".
However, smart (not stupid) people may still benefit from the book. Even generally smart people occasionally behave in stupid ways. Also, something often intuitively appears stupid, but you can't quite say why. Essentially, it looks like an Anti-Patterns book for business.
Ultimately, the difference between smart and stupid is whether or not you make mistakes. It's whether or not you learn from your own mistakes - or better still from the mistakes of other.
Why should I be loyal or obligated to someone who will fire my ass in a second, if the company's bottom line dictates it?
Think about it.
I have long since decided that my obligation is to my work only, i.e. that I will do my job and all of it the best I possibly can.
If a new employer comes along and decides to offer me better compensation or otherwise offer a better deal, I'm outta here just as fast as I would, if the company's quarterly earnings were dissapointing and they laid me off. At no circumstance will I EVER feel obligated to do anything just because someone has a fancier title than I do and is my boss.
That sort of stuff is for lambs.
I'm paid to do a job, nothing more or nothing less. That's where my obligation starts and ends.
In Soviet Russia, I ruled you
Actually, after having worked for others, both good and bad, and myself (having employed others), I've come to the conclusion that it's often not a mistake to believe the boss is the root of all evil.
A good boss is one that knows what you're meant to be doing, and communicates it to you effectively, then lets you do what you're hired to do, and get on with it.
The unfortunately all too frequent boss is indeed one who knows the buzzwords (after all, that's how (s)he got hired). After that, it's all about making themself look good.
I worked in one place, where the manager (actually, tech director) produced a lovely little Gantt chart with all the work schedules I was meant to be doing for the next 60 days.
All with pretty, and short titles, so they looked neat on the side of the page.
Unfortunately, on asking what the first 5 days of work actually entailed, I got the answer that he didn't know (and he wrote the project plan!).
Same with the second and third 5 days.
It took me 4 days of running round the company, talking with anyone I could find, until I found anyone (one of the sales chaps that met with the clients on a particular meeting) that had any idea what it was meant to be.
Then, it turned out the estimate was wrong.
Every step of the way, all I got from the boss was 'You're meant to be at this point now, the chart says so..'.
However, having worked for a great boss, I know the other side of things also.
That chap used to have a project planner talk to us, explain how we should tailor our estimates by bringing up questions about how long debugging would take, talking to other people, unexpected errors that always creep up..
In the end, he got reasonable figures from us on how long it would really take.
Higher management often didn't like the figures, but he let it be known that they could have crap for less time, and probably end up with people leaving, and a working solution for the time given, and hold onto experienced employees.
He then left us to get on with work, while intercepting all attempts from above to poke and prod us at our desks, and otherwise get in the way.
He was good enough at the job to know we weren't slacking, and a good enough manager to know how to get the best out of people.
That, trust me, is a great rarity in the business world, where it's often believed that the numbers are what people adhere to, rather than people defining what the numbers should say.
When the numbers say what people should be doing, you give rise to books such as the headliner for this topic..
This is not far from the truth. One of the chapters in the book is on why dBase is all but gone. The guy who was in charge saw a way to make money but alienating everyone who used dBase. He sued anyone who made a clone, interoperable program, or add on. He tried to blead dry all those who actually used dBase. As I read the chapter I laughed and laughed because it looked a lot like SCO all the way down to the CEO who could not shut up.
"Now we have the tablet PC from microsoft with handwriting software."
And by all accounts it is useless.
Handwriting recognition is HARD, and while Palm's stuff works, it's kind of cheating, since you have to conform to their writing style.
You had to do that with Apple's (unfoprtunately patented) technology. The joke was that they made it look like you were teaching the newton to recognize your handwriting, but in reality your Newton taught you how to write legibly. It was genious, honestly. I thought it was kind of funny going through the "training" sequence complete with lines right out of a "Big Chief" notebook from elementary school.
Handwriting recognition, or understanding strokes, is a difficult but nowhere near impossible problem. A 1991 Siggraph paper "Specifying Gestures by Exampe" by Rubine listed the 13 'features' used by most recognizers today. That is, 13 numbers derived from the actual pen stroke, although only a few of them are really needed. I've written my own using only 9 of those features, and using the Graffiti symbols (Palm's alphabet) have very good accuracy.
Other 'handwriting' such as marking menus or gesture-based commands (see /. headline earlier today about some) can be and are easily implemented using a few features from the Rubine feature set (angle, curvature, relative size based on the entire drawing, etc.)
So 'handwriting recognition' depends on your definition. Recognizing a set of specific, carefully crafted symbols as they are written can be done with very high accuracy. Recognizing the same symbols after drawing can be done, but its currently a little more difficult. Recognizing anybody's handwriting, including awful scribbles, at any point in the alphabet's history, is probably computationally impossible.
Two examples:
Example with 'bad handwriting' Draw an 'A', with three strokes, but don't connect the top peak: it could be an 'A' or it could be 'H'. Increasingly advanced recognizers are also looking at the context, since "T?E" and "H?T" are most likely to be 'H' and 'E' respectively. Palm (specifically the Graffiti alphabet) resolves this by making the symbols un-ambiguous. Sufficiently bad handwriting and poor grammar (ie: hasty lecture notes) will always cause problems.
Example with old script I've carefully examined documents ranging from the present day to copies of nearly 500-year-old script. Most old papers I've looked at, up until this century, had more curves and sharper corners. In the 1700's and 1800's, many people had fancy serifs, with especially practiced serifs on their names (like a spiral before starting an F or B, only one swirl on content, but 5 swirls on their signature). In the beginning of this centry, my own collection moves from spirals to sharp angles, then moves toward big curves+corners. I personally enjoy looking at the serifs on 'A' and 'F' from people who learned to write in the WWI time frame, especially the people who seemed to compose letters from connected sharp-cornered triangles and curves. Today's 'good' handwriting more closely mirrors what we expect to see in a sans-serif font, with exceptions on a few letters (F, D, B, q).
I am already seeing people draw 'E' as they would in Graffiti (two curls) rather than the traditional form of lines and angles. Personally, I don't see it taking too many more decades before our handwriting starts to evolve to a more recogniser-friendly style.
frob
//TODO: Think of witty sig statement
Not *all* decision making - just business decision making. The decision to completely rewrite the code was based on the merit of the code alone - not on the business or market implications. That is what Sposky and Chapman seem to be saying: programmers should program and leave business decisions to those that know the market.
There really isn't a good analogy that can compare to this. The decision was basically: stop all shipment of our product so that it can be completely redesigned, built, and tested or attempt to improve the already existing product. The fact that a competitor, with an inferior product, was able to continue shipping while making improvements points to the former being a bad decision.
This is, of course, all considered in a vacuum while looking at the end results. Other factors besides the code rewrite played a major role in how the "browser war" turned out.
Delivering good products *is* the goal. Given the choice between A) shipping inferior code that can be incrementally made better and B) shipping NO code while your competitor takes all market share, the choice is obvious. This is the case in every business: you seldom, if *ever*, want to ship NOTHING for months or years at a time (so that you can completely redesign your product) while your competitor becomes firmly entrenched in the market.