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.
The stupidest management/leadership advice book ever: Make It So, by Wess Roberts and Bill Ross.
And I say this as a Trek fan.
Schwab
Editor, A1-AAA AmeriCaptions
... is this book any more useful as a textbook for businesses than rah-rah stuff like In Search of Excellence? In other words, is it useful either to pick out really smart things companies have done, or really dumb things companies have done, and say "Do this, and you'll succeed; do that, and you'll fail"?
I'm not sure it is. Certainly the lessons of history are just as important in business as in any other field of endeavor. But a listing of successes and failures -- both, inevitably, filtered through the authors' biases -- does not constitute useful history in itself.
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
I've always wondered how DEC transformed itself from a great computer company (PDP-8, PDP-10, PDP-11, VAX, Alpha) to a historical footnote.
Mea navis aericumbens anguillis abundat
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
CS majors get it hammered into their heads that you don't try to program a solution that doesn't have a RESEARCHED solution YET. Otherwise, as Apple found out, you do the research while burning through your budget, and sometimes find the answer is several billion dollars away - if there even exists a solution that your team is BRILLIANT enough to find. Nuclear energy wasn't possible before Einstein for example. Is he on your team?
My CS courses contained several of these sorts of examples and my code design courses always emphasised KNOWING the solution BEFORE you start. Pity your CIS courses didn't.
I took a Management class in college where we spent a large amount of time focusing on some of the strategies successful companies used. It was all good at the time because the companies were pulling in massive amounts of customers and money. However several years after that class, these companies that were bragging about their innovative strategies were failing.
A few that I can remember was AOL and the Time Warner merger, Jack Welch and GE, and some others.
Just goes to show you, just because your successful in the short term with some crazy new strategy, doesn't mean it is a good one.
If the lessons in the book were that obvious, why would the RIAA be waging war on its own customer base? Or SCO emboiled in a series of ever-escalating court battles (rather similar to a seige) that will one way or another end in its destruction? Or (here's some flamebait) why did our government send troops halfway across the world without any sort of good plan on what to do after the battle was over?
Jesus's advice in the Bible seems pretty clear too - be nice to people and they'll usually be nice to you. Yet after 2,000 years we also haven't gotten that one down. (and Christians are often the WORST offenders...)
Bush: He's Liberal in all the wrong ways.
Amazon Link
It is by the juice of the coffee bean that thoughts acquire speed, the teeth acquire stains. The stains become a warning
This is one aspect of diversity that's often overlooked. As we try to ensure that departments and companies have a sprinkling of various races, genders, creeds, and personality types, one thing that's often overlooked is that not everyone within a group needs to be a "caffiene achiever." There are perfectly good workers who aren't interested in a promotion, but are happy doing what they're doing - very often, they're dependable and are worth their weight in gold in a pinch.
An example would be a night-shift computer operator. I had that position as a 23-year old, but moved up the first chance I got to the daytime shift, then programming, etc. For the department, the next couple years were a constant hassle of finding people to adequately fill the night shift - either they didn't stick around long, or (in one unfortunate case) were more interested in stealing laptops than actually working. Eventually, we found an older guy who was a few years away from retirement and was interested in steady work. He took the position, and has performed well in it for the last 5 years.
I guess the overall lesson is that customer satisfaction can often by strengthened by dependability, which can suffer when management is constantly reshuffling teams in search of marginal improvements.
Stop by my site where I write about ERP systems & more
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.
I read this book... don't waste your time if you are remotely familiar with computer and tech history.
"Ain't I a stinka..." - Bugs
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
The problem is that there is no right answer. A commonly used analogy is this.
Let's have 100 people flip a coin. If your coin ends up heads take a step forward, if it turns up tails take a step back. After a thouand flips can the guy that's in first place honestly say he was successful because he flipped good?
Every day people make a thousand decisions based on the information they have at the time. In retrospect some of those decisions turned out to be bad but at the time there was probably a perfectly good reason for doing it.
It seems to me the biggest factor in being a successful company is to have enough padding to be able to make lots of mistakes and still survive. MS has a monoply and that monopoly enables them to make hundreds of mistakes and still survive. They can afford to gamble and hope that they get one hit out of a hundred misses. Netscape, Apple and other companies don't have that luxury. One mistake and they die, if they don't die it takes years to get back up on their feet.
Finally the biggest mistake management makes is thinking that their enemy will act like them. Since most people are basically honest and decent they tend to presume that their competition will act in an honorable way. When the opposition desides to act in horrible, sleazy and illegal ways to beat them they get surprised and get beaten. Your competition will lie to you, act like your firend, sign contracts with you, and then steal your techonologies, customers and vendors and then turn around and drive you out of business. As Bill Gates said once "hold your friends close, hold your enemies closer". He knows exactly how to win and he also knows that winning has nothing to do with morals or ethics. He knows to leave his morals at the door when he enters the MS campus.
War is necrophilia.
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.
If you think this is the case you should not live in a capitalistic country. It's just not the way things work.
You must tolerate inefficiency, stupidity, etc for a while, after which you MAY get the chance to undo some of the damage.
You need to convince the people who don't know their own field and the people with wrong (as in not conforming to your view of the world) assumptions both think of you as useful and not dangerous to them (I'm still working on the not dangerous part).
Outclassing people in an attempt to gain something will not work. Even though it constructs a better product it's a destructive action, which not only shows that you have the ability to attack others, but that you're good enough to succeed. So don't do it.
A good product is very simple, in the end gain > losses. I believe netscape 6.0 does not satisfy that condition. Even though the code is good (I've had a demo, and indeed, it works very nicely, it all clicks together perfectly) it is a complete disaster.
The "good" product managed to destroy the entire product line of the company creating it. It may be interesting from an artistic point of view (and therefore appeal to open source programmers) but the product sucks.
I think some of the other replies are looking at this the wrong way - it is *not* always the right decision to keep bolting on new functionality to an old and broken infrastructure. Even when the alternative is not shipping anything for X years, that may be a better decision.
*However*, in the case of the internet browser business, this was a bad decision. Why? Because the goodness of a browser isn't based solely on the features it supports, it's based on how widely it's programmed to. In some other situation, it might have made sense to release nothing ... you let the competitor have the market for a few years, then show up with the super-powered new version and everyone switches back. If you've got the capital, make the investment. (Note that this seems to be what MS is doing with Longhorn - check back in 5 years to see how it worked out)
With the browser, however, once Netscape stopped shipping product people stopped using it, and the web went to supporting just IE. The point is just that in the particular case of the browser, because it's not a stand-alone technology but a platform, and so its "goodness" is a function not just of the platform but of what supports it, the rewrite decision was, well, ill-advised. In short, they didn't understand their business.