In Search of Stupidity

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.

Comments

Good management advice

[scumbucket]

I turn to OSDN and the various /. editors for my management advice.......

Found it.

[grub]

In Search of Stupidity

Your search is over.

Re:Found it.

[IFF123]

An obligatory despair.com quote:
Never underestimate the power of stupid people in large numbers...

Re:Found it.

[wafflemonger]

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.

Why not

[Evil Adrian]

Find someone in your family that has management experience and is successful, and ask them for advice?

If you don't have anyone in your family that has successful management experience, then it's just not in your genes. Give up now.

It wasn't lying, it was a matter of emphasis.

[harriet nyborg]

"We didn't fake the data. It's called an aggressive headline."

Now where have we heard that before? At least these guys will be able to get a job in the Bush administration.

Re:It wasn't lying, it was a matter of emphasis.

[Anonymous Coward]

At least these guys will be able to get a job in the Bush administration

I don't know about that. Along with their campaign call center, I'm pretty sure they outsourced that to India, too.

Re:Blue collar envy

[BillFarber]

Most managers work for the better of the company and are burdened by workers who "just work there". No sense of loyalty or obligation to the ones who hired them in the first place.

On the flip-side, there are quite a few IT professionals that get products completed inspite of the (non-technical) bosses who are only trying to further their own career. Loyalty works both ways. Why should I be loyal to a company that might lay me off next week and outsource the work I'm doing?

The CIS majors must know something the CS don't

[hellfire]

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.

Yes it is, and Apple did it. This is not a pro apple rant, but the 1.1 release of the Newton handwriting recognition system was lauded as "pretty good." That's something funny to say, but at the time no one came close to that level except for Palm. Palm has a handwriting recognition system that also works very well, except you simply have to write a certain way, and it doesn't recognize your specific style. Now we have the tablet PC from microsoft with handwriting software. Exactly what is so impossible about handwriting recognition?

I was a CIS major, and hell I didn't know handwriting recognition wasn't possible? I always thought the CIS majors were smarter, and now I have proof!

Re:The CIS majors must know something the CS don't

[jc42]

Back in the 1970's, a bunch of guys at Rand implemented a very successful handwriting input package. It even included an editor that used a lot of the standard editor's marks to make changes.

They commented that there was a serious misunderstanding of the difficulty of handwriting recognition: If you want the computer to take a page of handwriting and recognize everything on it, that is nearly impossible. But if the computer can follow the handwriting as it is written, the job is fairly easy.

They also made the point that their software was typically only around 90% accurate (counting characters) when a person started using it. But it improved quickly. This wasn't because the software learned your writing; it didn't. It was because, when it drew the wrong character, you did it over until the software got it right. This trained the person to write in a way that the software could recognize. One side effect was that users of their system had noticably better handwriting after a few days.

But reading a sheet full of handwriting is still a very difficult task for a computer. Is there any software that does it well enough that you don't have to edit the results?

Re:The CIS majors must know something the CS don't

[rifter]

"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.

Re:Blue collar envy

[MuParadigm]

"No sense of loyalty or obligation to the ones who hired them in the first place."

After years of down-sizing and raided pension funds, many employees have learned their sense of coporate loyalty and obligation from the corporations themselves.

And I hardly see how this is a "blue-collar" experience.

Best Management Book ever written?

[JayBlalock]

I'd say Sun Tzu's 'The Art of War'. Despite being 2,500-odd years old, I can't think of any single text with more plain useful advice for how to manage a major competitive venture of any sort.

One who knows the enemy and knows himself will not be in danger in a hundred battles.

One who does not know the enemy but knows himself will sometimes win, sometimes lose.

One who does not know the enemy and does not know himself will be in danger in every battle.

Re:Best Management Book ever written?

[Rinikusu]

Are you a military history buff? I'm by no means not, but you know, as straight-forward as you seem to make it sound, it appears that Sun-Tzu's teachings would have been sorely needed by many. /* I mean, "Attack him where he is unprepared, appear where you are not expected." Well. Thanks for that advice. And here I was doing the opposite, attacking where prepared and appearing where expected. Silly me. */

Imagine had Saddam's generals had thought to extend their line so the famed "hail mary" would have been actively opposed? Apparently, Saddam's generals were not thinking about those principles in their defense planning. And let's look at all those wars with straight lines of troops, battling on flat terrain and what not back in the 1700's and 1800s. And now witness the "resistance" in Iraq: We are totally unprepared to fight a guerilla war with conventional troops. Most of our technology and training is still heldover from the Cold War where we envisioned broad, sweeping formations and movements between huge masses of men in Eastern Europe. Which is great when you're fighting conventional formation warfare. But when your enemy instead becomes a couple people whipping up homemade bombs with readily available materials and blowing up your troops a couple at a time.. The "terrorists" are certainly attacking our Army where we are unprepared and not expected. /* Hey. Worked well for Napolean in Russia, didn't it?*/

Actually, yes, it did. It was the Weather and lack of preparation (see fertile country comment). Napolean may have overestimated his force or underestimated the Russians understanding that all they had to do was stall his forces enough until Winter came. At which point, the foreign forces would have to deal with the weather AND locals used to the weather. Napolean came trudging back to France in defeat, however his forces were still loyal to him and from my recollection, came to his call when he reascended power. /* Deep. Very deep. */

You'd be surprised. Many armies have sufficient manpower, but insufficient logistics to keep those lines supplied. Food, fuel, etc. The Chinese continually outpaced their supply lines during the Korean War. In the Winter. Which meant they had to stop and wait for food and what not (the Korean Peninsula is apparently very infertile during the winter, at least my mom told me that..). Because of modern warfare, it's not enough to just be able to steal your food, you've got to provision for fuel, etc. Why did it take as long as it did to advance to Baghdad? Because we couldn't risk outrunning our fuel trucks, and securing the routes that the convoys would travel. /* I could see how this practical advice could be useful, for those of us who indeed make no mistakes. */

Your comment actually makes sense. Everyone makes mistakes. In fact, many mistakes that are made are not seen until after they are exposed as mistakes. See Gulf War I. I believe that in hindsight, those Generals in charge of defending Iraq saw the flaws in their defense that allowed the virtually unopposed American forces to enter Iraq.. However, I think the intention is: Strive for perfection. Doing it half-assed is a recipe for disaster. Think and double think your moves and assess and reasses your data. If it's worth doing, do it right. That sorta thing.

Speaking of which

[Otter]

I was browsing the local tech bookstore a couple of years ago, when Enron was all over the front pages, and noticed a book with a tilted E on the cover. I asked the staffers "Is this book "How to Succeed by Imitating Enron" on sale? They all burst out laughing, conferred and decided to mark it up as a collectors' item instead.

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.

I dunno -- it's pretty much accepted among zealots that Apple management between Steve and Steve was disastrous. Most of us can't hear the word "ameliorate" without cringing.

So what?

[paiute]

The easiest thing in the world is to look back and deride the losers while applauding the winners and point out why each is what it is. It's a little harder to pick them in advance.

What do you get out of reading this book? Unless it is some tools for making predictions, you might as well rip out the pages and wipe your ass with them.

As for Netscape vs. Microsoft, well, if you can't figure out why that happened (clue: it had nothing to do with Andreessen being an idiot or deserving to die), then you have no business attempting to analyze more subtle corporate interactions.

Re:The question is ...

[borkus]

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.

Hyperbole

[hacksoncode]

If CIS majors were smarter, you would have realized that what he meant was: "handwriting recognition that is good enough to be usable and not to piss many people off isn't possible for the reasonably forseeable future".

Re:DEC

[A nonymous Coward]

DEC was like Data General and every other mini-computer maker. They thought they had eliminated, or were eliminating, all rationale for mainframe computers. What they really had done was point out the path for computers cheap enough for small groups who couldn't afford big computers, and couldn't get any satisfaction from the corporate mainframe computer center. The PC was just an extension of this decentralization. But these minicomputer makers were too arrogant to understand that, and laughed at PCs as being useless. They didn't realize that just as small departments might want their own computers, so might individuals.

no surprise

[agusus]

Apart from the minor detail that some of the data in the book was faked.

Well, DUH. What else did you expect in a "management bible"??

Re:Blue collar envy

[gorbachev]

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.

Best management guide: OfficeSpace

[Helpadingoatemybaby]

As an expert on stupidity (I have worked for many stupid people over the years, and have often been one myself) I can make some recommendations.

I have now become the "stupid manager" of my small but growing business and I've realized that I just have to remember what my stupid bosses did over the years, and don't do what they did. Sounds easy, but it isn't. I just saw OfficeSpace again. I saw a little of myself. I was afraid.

Bosses like improvements. Radical change. Go faster, go faster. They tend to like this because that's how they got where they are -- right or wrong they tend to have hard driving personalities. Employees don't like constant change, in my opinion. No one likes coming to work and finding a new policy on their desk about their TPS report cover sheets. Change is useless much of the time.

I call this "overbehaviour." Doing something -- anything -- because it... just needs to be improved! Most improvements aren't.

So now that I'm the boss I'm trying to change as little as possible. Try and keep things in a rhythm and ask people to help come up with ideas. Not for internal processes, but for products. And then, give control of that idea to the guy who came up with it. It's his baby, let him nurture it. Let him take credit for it. People tend to live up or down to your expectations.

Use this to make the customer happier.

Ultimately, that's all that matters.

Never ask

[BillsPetMonkey]

management consultants. Ever thought what management consultants do? I used to be one. They get paid good money to dress unpopular decisions up as the results of their 'independent studies'. What do they actually know about management? I graduated in history and started with a consultancy 2 years after graduating. There is never an industry as nepotistic and bent as management consultancy - that's how I got the job (through a friend).

My advice? Ask the oldest guy (or the person who's been there the longest) in your company what they did last time the same thing happened. They usually know, but you might not know that.

Joel Sposky's preface makes me puke

[RealProgrammer]

Netscape's monumental decision to rewrite their browser instead of improving the old code base cost them several years of Internet time, during which their market share went from around 90% to about 4%, and this was the programmers' idea. Of course, the nontechnical and inexperienced management of that company had no idea why this was a bad idea. There are still scads of programmers who defend Netscape's ground-up rewrite. "The old code really sucked, Joel!" Yeah, uh-huh. Such programmers should be admired for their love of clean code, but they shouldn't be allowed within 100 feet of any business decisions, since it's obvious that clean code is more important to them than shipping, uh, software.

Hindsight is 20/20. If Marc Andreesen said the code sucked, and needed a rewrite, then it sucked and needed a rewrite. How long would it have taken to add all the latest features to the old code base?

Microsoft had the Mosaic code. They were not going to rewrite it, even though it sucked, because that would not be "good business". They sold the sucky product to win a short-term victory, and they're still doing it today.

Delivering good products should always be the goal. Given the choice between A) competing against Microsoft at repackaging bad code and B) rewriting the code completely, the choice is obvious.

Sposky and Chapman appear to believe that market domination defines correct decisionmaking. Criticize people for not understanding the business they're running, but don't criticize them for having integrity.

Re:Joel Sposky's preface makes me puke

[oskillator]

Sposky and Chapman appear to believe that market domination defines correct decisionmaking. Criticize people for not understanding the business they're running, but don't criticize them for having integrity.

Criticizing people for not understanding business is precisely what Joel was doing. Delivering good products not the goal of a software company; making money is. Making a good product is a luxury, and it turned out to be one that Netscape couldn't afford. Staying stagnant for three years while your competitor's product is making steady improvements is not the path to victory.

Also:

If Marc Andreesen said the code sucked, and needed a rewrite, then it sucked and needed a rewrite

I'm pretty certain you're not attributing godlike infallibility onto Mr. Andreesen, but I can't parse this sentence any other way. What is it you're trying to say?

Re:Joel Sposky's preface makes me puke

[MrWa]

Sposky and Chapman appear to believe that market domination defines correct decisionmaking. Criticize people for not understanding the business they're running, but don't criticize them for having integrity.

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.

Re:Blue collar envy

[*weasel]

corporate loyalty requires trust on both sides.

the default 'trust' that employees have for employers is gone. Wildly growing management compensation vs the stagnation of working wages, raiding of benefits packages, downsizing, outsourcing, fly-by-night conversions of 401k shares into company shares... why again should the workforce trust the average company?

when a group of guys is doing unpaid overtime in serious crunch mode to ship software, only to be put on the street with no severance just after the code is turned in, 2 weeks before christmas, not in a noble attempt to save what part of a failing-company that they can, but rather to -maximize-profit-, all the while petitioning the board 'forgive' a multimillion dollar loan for a gulfstream... well, i don't exactly see where the employee is making a mistake by taking the realist viewpoint of 'i just work here'.

sure, the boss is not necessarily the root of all evil. but the employee is well served to assume that he is, until such a time as he has proof that he is not. and in our current employment situation, that just isn't happening by and large.

Best practices? I can sum it up in three points..

[pla]

You don't need a book to tell you how to manage people well... It boils down to just a few simple points:

1) Break down the "big" tasks into personal-project-sized chunks. If a large number of underlings complain about the size of those chunks, adjust accordingly. If one or two people complain, tell them to quit whining.

2) Leave people alone to do their work. Realize that deadlines will occasionally slip, and some people will have bad weeks on occasion. If one or two people consistantly underperform, axe them. If everyone consistantly fails to do their work in time, the problem sits at your own desk.

3) Give people a reason to remain loyal and do their work. Money obviously forms the single biggest motivating factor, but pride in their work, credit for exceeding expectations, and comfort in their jobs matters quite a lot as well. If your best worker always comes in at noon and leaves at eight (at a 9-to-5 company), don't complain, but rather appreciate that someone knows when they do their best work. Same applies to attire - Unless your underlings deal directly with the public, every day should count as a dress-down day, within reason. PJ's obviously do not seem acceptible, but jeans and a T-shirt? A tie doesn't make people more productive, despite what management-types seem to believe. It just makes them uncomfortable.


Overall, I suppose I can sum this up in two abstractions - Treat people like you would like them to treat you (golden rule, basically); and, if everyone seems to complain about you, don't assume you have a lazy team, start looking at your own job performance.

Re:Blue collar envy

[malkavian]

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..

Re:Blue collar envy

[MrResistor]

Most managers work for the better of the company and are burdened by workers who "just work there". No sense of loyalty or obligation to the ones who hired them in the first place.

Only an idiot, or someone completely ignorant of standard business practices over the last few decades, would blame lack of employee loyalty on the employees.

Here's a clue for you: Loyalty is earned. Companies that show loyalty to their employees have loyal employees. I think it's kind of funny when allegedly highly educated MBAs can't understand that basic relationship.

Microsoft's big mistakes

[roca]

> According to Rick Chapman, the answer is
> simpler:
> Microsoft was the only company on the list that
> never made a fatal, stupid mistake. Whether this
> was by dint of superior brainpower or just dumb
> luck, the biggest mistake Microsoft made was the
> dancing paperclip. And how bad was that, really?

Microsoft's past is littered with failures: Microsoft Bob, early versions of Windows, early versions of PocketPC, all versions of Smartphone so far, the original MSN "Blackbird", LAN Manager, UltimateTV, Windows At Work, Windows DNA, and huge internal projects like Pyramid and Cairo that never even saw the light of day --- these are just some of the examples.

None of these mistakes were fatal simply because Microsoft could always fall back on the revenues of their OS monopoly, and later Office monopoly.

It gets my goat when people point to companies like Netscape and say "they deserved to be crushed by Microsoft, because they made mistakes". Everybody makes mistakes. The difference is that the monopolist gets a lot more lives.

Ditto for Intel. What other company could have survived the IA64 debacle? Yet Intel has, on the back of its x86 near-monopoly.

Re:Handwriting recognition not possible

[Frobnicator]

Rather than throw around claims about one group not knowing the impossible and another group able to pull it off...

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