If this book report seems a little heavy on the questions? It's because it's the first draft of a study guide? For people reading the book? Oh man it's way too long? But hey give me a break, it's a first draft?

The Mythical Man-Month

This is a study guide for folks reading the Mythical Man-Month. When reading a book like this, it's useful to have some questions buzzing around in the back of your brain. In case you don't already have enough of those, this study guide provides a few extra.

This book is about managing large software projects. Fred Brooks wrote it in 1975; back then, there wasn't a big literature about such things. There hadn't been many such projects. Many of them had been debacles; nobody wanted to brag about them later. Actually, Fred Brooks had presided over something of a debacle himself--his project was famously late. This book is a post-mortem: why things went wrong, lessons learned, how we can (or why we can't) avoid similar stumbles.

Pick up a recent edition of the book--the 20th anniversary edition includes chapters at the end pointing out which parts of the original have [not] withstood the decades. E.g., the Waterfall Method of project planning isn't SOP anymore. In the preface, he also points out something important about software project management reports in general:

In preparing my retrospective and update of The Mythical Man-Month, I was struck by how few of the propositions asserted in it have been critiqued, proven, or disproven by ongoing software engineering research and experience.

As you read this book (or anything), always be on your guard for snake oil, untested assertions, and handwavery. Some techniques will help your team, some will harm it. Learning to recognize which are which is an important part of leadership.

Preface to the Original edition

Brooks gives us the whole book in a nutshell in the Preface.

I wanted to explain the quite different management experiences encountered in System/360 hardware development and OS/360 software development.

...

Briefly, I believe that large programming projects suffer management problems different from small ones, due to division of labor. I believe the critical need to be the preservation of the conceptual integrity of the product itself.

Got that? He's telling us that Management is important. He's saying that Leadership is important. He's saying that Design is important. 120 people produce no more than 12 do if they're not working towards the same goal. And unless you can help them all see where that goal is, they will not all work towards it. He's not going to teach you new algorithms, tools, none of that. This is people skills. He's reminding you that this stuff matters.

The Tar Pit

Brooks' OS/360 debacle was largely a schedule slip. Here, he points out that junior programmers are optimistic about how long it takes to implement part of a large system. They don't think about the (considerable) time it takes to provide the correctness and polish they'll need to be part of a real-world product. the (considerable) time to design and implement the interface between their system component and the rest of the system;

Try to remember your first projects working on larger software systems. It took longer to get things done than your quick-and-dirty hacks for school homework assignments, didn't they? Where did the time go?

As a rule of thumb, I estimate that a programming product costs at least three times as much as a debugged program with the same function... A programming system component costs at least three times as much as a stand-alone program of the same function.

If you're not sure whether a junior programmer has considered these things, their schedule guesstimate might be 9x optimistic. When you get an estimate from a co-worker, how can you find out whether they've allowed for correctness and API design?

In practice, actual (as opposed to formal) authority is acquired from the very momentum of accomplishment.

The Mythical Man-Month

Here, Brooks points out more things that go wrong with managing schedules. They're hard to estimate. They're hard to boost, too. This chapter gives us Brooks' Law: "Adding manpower to a late software project makes it later." When you add new people to a project, for the first few months, they slow you down as you teach them things and they bump into things. Only later when they're up to speed might they help your schedule. Unless they slow down trying to manage them.

Why would anyone ever think to throw people onto a project at the last minute? Maybe a clue is the context in which this book was written, IBM in 1975:

I wanted to explain the quite different management experiences encountered in System/360 hardware development and OS/360 software development.

Maybe back in 1975, most of IBM's experience was with hardware. If design went slowly, maybe there was a temptation to make up time with more people: run extra shifts at the manufacturing plant.

The need for intercommunication slows everyone down. Can we ease this by designing better interfaces? Can we design our software architectures so that not every engineer needs to pester every other engineer to learn every interface?

Gutless estimating It's bad enough that the junior engineers on your team underestimate how long it will take them to accomplish something. Sometimes an executive does, too. They lean on you, that's no fun. Something that happens at often at some companies: someone pre-announces an unrealistic date to the world. Do you have any stories like this? If not, ask some veteran programmer to tell you some. Maybe buy that veteran a drink first--they tend to be sad stories. In hindsight, could the teams have dodged these disasters?

The Surgical Team

This chapter explores the idea of a small programming team. Some parts of this idea have aged better than others.

Aged well: team of people with complementary roles and diverse skill sets.
Aged less well: some of the suggested roles now seem absurd.

Brooks thinks that every senior programmer needs a secretary. And an editor (tech writer) and another secretary for the tech writer. Brooks was a writer in a time of typewriters, large presses, and other awkward tools. Nowadays instead of giving the senior programmer so many people to manage correspondence and documentation, we have Gmail and the wiki. The "program clerk" role largely went away when revision control systems came along—a few admins can "clerk" the "programs" of many, many engineers.

Suppose you wanted to plan a "surgical team" for your organization in the modern day. What roles would it have? What assumptions do you need to make about how this team would fit in to the organization at large?

Aristocracy, Democracy, and System Design

If one person designs a system, that design captures only one person's knowledge. For a large system with many differrent pieces, some pieces' designs will be clunky.

If many, many people design a system, that system never gets designed.

Brooks praises Reims Cathedral:

The joy that stirs the beholder comes as much from the integrity of the design as from any particular excellences. As the guidebook tells, this integrity was achieved by the self-abnegation of eight generations of builders, each of whom sacrificed some of his ideas so that the whole might be of pure design.

Invoking a cathedral as metaphor might set of alarm bells in your head. Didn't ESR use that same metaphor in his essay The Cathedral and the Bazaar? There ESR praised the "bazaar" over the "cathedral": harnessing hundreds of open source folks to work on a project instead of a small, limited group. But that essay points out that some tasks scale better than others. He wrote

So does the leader/coordinator for a bazaar-style effort really have to have exceptional design talent, or can he get by through leveraging the design talent of others?

I think it is not critical that the coordinator be able to originate designs of exceptional brilliance, but it is absolutely critical that the coordinator be able to recognize good design ideas from others.

Brooks and ESR would agree that you can't just let loose a horde of 150 programmers and hope that a great design emerges. You need some architects with "taste".

How much of a system's design should the architects figure out (leaving details to the horde)? Brooks thinks it's the interfaces: the APIs and UIs:

By the architecture of the system, I mean the complete and detailed specification of the user interface. For a computer this is the programming manual. For a compiler it is the language manual. For a control program it is the manuals for the language or languages used to invoke its functions. For the entire system it is the union of the manuals the user must consult to do his entire job.

Suppose you're Fred Brooks and you have 15 great programmers and 150 good ones. How might you divide tasks between them? What are some ways you could set up bottom-up feedback without drowning in noise?

The Second-System Effect

Have you ever worked on a "second system"? You work on a successful system. It's working. You look for ways to improve it, to "get it right." You get around to elegantly adding those improvements that you couldn't "bolt on before". And somehow... the result is a mess. Years later, you figure out that many of those "improvements" were gratuitous; some of them made the system worse. Have you? Or seen one from a distance?

How can we guard against this effect? Brooks says every design team needs a third-system veteran, someone who has experienced their second system. How might a system like this work at your organization? Anyone can design something, you can't force them to take advice from a veteran. What can you do?

Passing the Word

This chapter is mostly of interest to the historian, or people who like to hear stories of the old days when "we had to walk back and forth through the snow, twenty miles, uphill both ways".

The book assumes that most of a project's "architecture" happens up front, then stays frozen. Wow, it's the opposite of agile. This chapter explains the clumsiness: This chapter talks about project communications back in the 1970s.

Back then, communicating a spec change was a major ordeal. Word processor software was a newfangled clunky thing. There was no revision control system software to keep track of changes. There was physical typesetting; physical pages to truck to far-flung teams.

The section titled Conferences and Courts talks about their change process. He mentions that it happened less often than it should have--Brooks wishes that his architecture team had been more agile. But when you hear about what it took to communicate a change... it makes one glad to be working in these relatively easy times.

Why Did the Tower of Babel Fail?

It's another chapter about the difficulty of communication, but this chapter describes problems that are still with us.

So it is today. Schedule disaster, functional misfits, and system bugs all arise because the left hand doesn't know what the right hand is doing.

Part of the chapter describes the 1970s solution: write everything down. Since they didn't have an intranet and a wiki, and they generated a lot of information, they used microfiche. Ha ha ha. If you get bored reading about 1970s communications technology, you might skip ahead to the section titled Organization of the Large Programming Project

Like the "Surgical Teams" chapter, this section discusses roles. But instead of people working on a small team, these roles are the "diplomats" that keep those teams moving in the same general direction: producers and technical directors. If you work on a large project, who are the people who have this high-level role? How would you decribe their roles? What challenges do you think they face?

Calling the Shot

This chapter has more ponderings on schedule estimation, including some still-relevant thoughts about why things might take longer than you'd expect. Along with this, there are some good reasons for "fudge factors" to apply when you hear a schedule from a naive estimator.

Have you ever estimated how long it would take you to complete a task? How far off were you? Why?

Has someone else ever estimated how long it would take you to complete a task? Why was their estimate so far off?

Have you ever estimated how long it would take someone else to complete a task? How far off were you? Why?

This chapter measures programming output in Lines Of Code. Yes, people really did this back in the 1970s and '80s without irony.

Ten Pounds in a Five-Pound Sack

This chapter discusses the tragedy of metrics: once programmers know what you're trying to measure, they will optimize for it, sometimes at the expense of overall system quality. E.g., if you tell programmers to use less memory, you might notice the system slows down with swapping:

...Digging-in showed that the control program modules were each making many, many disk accesses. Even high-frequency supervisor modules were making many trips to the well, and the result was quite analogous to page thrashing.

You need to measure things, but leaders need to make sure that things stay on track.

The project was large enough and management communication poor enough to prompt many members of the team to see themselves as contestants making brownie points, rather than as builders making programming products.

Have you seen this kind of problem, where a high-level strategy gets mis-applied at the low level? Could a different approach have yielded the benefits without the low-level problems?

Representation is the Essence of Programming is a fun section, reminding us of the importance of designing our data structures.

The Documentary Hypothesis

Brooks was a writer; it's no wonder that he advises that a project's mission, architecture, and everything be expressed in writing. This chapter describes some things worth writing down. If your customers can see your source code, then API documentation is simple. But he wants more.

One document he suggests maintaining is an org chart:

This becomes intertwined with the interface specification, as Conway's Law predicts: "Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations." Conway goes on to point out that the organization chart will initially reflect the first system design, which is almost certainly not the right one.

Even with our great software tools, editing an org chart is tricky. People get tetchy when you mess with it. Some inertia is good. Brooks advises some inertia in changing system documents, too... and not just because of clunky 1970s documentation technology:

...the best engineering manager I ever saw served often as a giant flywheel, his inertia damping the fluctuations that came from market and management people.

Have you worked with customers before? What sorts of second-guessing have you had to apply to their suggestions? How do you prioritize their requests?

The task of the manager is to develop a plan and then to realize it. But only the written plan is precise and communicable.

How much precision do you want in a plan? Are there other ways you might communicate it?

Plan to Throw One Away

Twenty years later, Brooks was no longer fond of this chapter. This chapter points out that your first attempt at implementation might not be good; it's OK to scrap it and start over. Later on, as he moved away from the waterfall model, Brooks was OK with the idea of more incremental improvements.

But there's still some good advice here:

Project after project designs a set of algorithms and then plunges into construction of customer-deliverable software on a schedule that demands delivery of the first thing built.

Have you ever been on such a project? Did your customers forgive you?

Plan the Organization for Change reminds us of tricky things to keep in mind when changing things.

Management structures also need to be changed as the system changes. This means that the boss must give a great deal of attention to keeping his managers and his technical people as interchangeable as their talents allow.

I'm not sure I've ever seen a management structure change that was described as in response to a system change. Have you? What was the reason? How was it communicated?

Sharp Tools

This chapter is mostly of interest to the historian. It's a fun read, but if you're in a hurry, I'll summarize it for you: tools are better now than they were in the 1970s. We gripe about our tools, but they are awesome.

The Whole and the Parts

This chapter discusses the creation of high-quality systems:

• Writing a spec clear enough such that folks know what the system is supposed to do.
• Test the program.
• Debugging: excel at it.
• Don't try to integrate all changes at once.

Have you worked on a large project? How did the project find bugs hidden in the spaces "between" modules worked on by multiple teams? Did teams do anything to make this easier?

Hatching a Catastrophe

Earlier, we learned that everyone is terrible at estimating software development schedules. Here, we learn that they're also terrible at noticing schedule slips. He recommends using scheduling software to find bottlenecks and watch those carefully.

The bosses also need to let underlings safely report schedule slippage.

Have you worked on a project that had a schedule?
Have you worked on a project that did not have a schedule?
Any differences in the projects that could be attributed to the difference?

The Other Face

This chapter discusses how your product interacts with customers: usability and documentation. Some parts of this chapter have aged better than others.

The flow chart is a most thorougly oversold piece of program documentation. Many programs don't need flow charts at all; few programs need more than a one-page flow chart.

Flow charts have fallen out of favor. What would you say are the most oversold pieces of program documentation nowadays?

The chapter has some interesting ideas about using code comments to clarify code. What did you think about using ASCII art arrows to show the path of GOTO statements? Do you still think C is a primitive programming language, now that you've seen PL/I?

No Silver Bullet--Essence and Accident in Software Engineering

If you're reading an old edition of the book, you don't have this chapter. Fortunately, it's out there in a place called the internets.

This 1987 essay points out that software development had made great strides recently. Software development was getting faster! But the easy speed-ups were gone: the remaining problems could not be so easily knocked down with tools.

Our tools were getting really good at dealing with the same problems. But the essential problems hadn't been tackled at all.

I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared to the conceptual errors in most systems.

Putting together a software system isn't like assembling homogeneous bricks.

...it is necessarily an increase in the number of different elements. In most cases, the elements interact with each other in some nonlinear fashion, and the complexity of the whole increases much more than linearly.

And of course, by the time you design a decent solution, the requirements have changed

The software entity is constantly subject to pressures for change. Of course, so are buildings, cars, computers. But manufactured things are infrequently changed after manufacture; they are superseded by later models, or essential changes are incorporated in later serial-number copies of the same basic design.

How can we approach some of these essential problems? If we want to do something similar to what others have done before, we might be able take advantage of their work; e.g., if you want to write a simple database-backed web application, there are several platforms that make this pretty easy. But probably the very fact that you're thinking about large-scale software development means that you're thinking about some project that's not so straightforward.

When you consider the lifetime of a major software project: the evolution from hallway conversation to design to tinkering to large-scale development to refinement to deployment to support to maintenance and improvement: where does the time go? If you wanted to accomplish all this with half the effort, what would need to change?

Some of Brooks' possible-solutions-on-the-horizon have come to pass, at least partially. Are there any of these that you think might speed up software development further in the future? Or have these veins been mined out?

I'd heard that William Gibson had written Pattern Recognition, this book that wasn't science fiction. So I didn't read it. That was years ago.

More recently, I read Spook Country that wasn't exactly science fiction. It had some science-fictiony elements, but they were just a few years out. I'd been tricked into reading non-science fiction by an author I thought of as locked in a genre! But I'd liked it anyhow. So I gave Pattern Recognition a try. OMG, it is awesome! It is better than science fiction--like Douglas Coupland, Gibson has teased out some aspects of real life which are even better than science fiction.

• signals intelligence
• historical computing devices
  • Curta!
• the decline of undirected brand-based advertising
• the rise of astroturfy viral marketing
• did I mention Curta?

Oh yeah--and there's a plot and characters and plenty of references to pattern recognition, both as it relates to signals intelligence and to other things. So you can feel all brainy and literary as you read along and pick up on allusions and tsk at characters who make bad decisions.

This is an old textbook about applying cryptography; that is, it's about computer security. It's the textbook by Bruce Schneier, the book he later said wasn't so important--you can get this stuff right and your system still might not be secure. Your fancy security system might not do much good if everyone in your company's art department thinks its easier to trade passwords than to set up a shared file server. But I read it anyhow--some pieces of security still seem useful.

It's an old book; people crack codes over time. This led to some disappointment while reading. I got kind of excited to read about FAPKC, a Chinese cryptography system based on cellular automata. This was cool on a number of levels, and not just because it evoked a puzzle from the No More Secrets game. But it turns out that FAPKC was broken back in 1995--probably at around the time this book was slogging through the book publishing process.

I'm glad I read this book; this book made me think. It's not just about the crypto; it's also about protocols built up from crypto. Suppose you have a way to encrypt messages, a way to sign messages. How do you exchange data with someone without being eavesdropped upon if you haven't already exchanged keys with them? OK, you've probably already stumbled into key-exchange protocols. But there are weirder things out there. This book talks about several of them--including how some protocols were found vulnerable. It's good exercise to think about these things, try to figure out how you would crack them. I didn't always succeed. There's another good lesson there--sometimes you can look at a broken system and think "well, it looks OK to me". Trust no-one, least of all yourself. This book had plenty of good puzzles dressed up as protocols.

There was a quick run-through of useful mathematics. This was a nice refresher for stuff I already knew. For the stuff I didn't know--number theory--this wasn't enough to teach me much. But there were references to books with more information with some recommendations, so there's hope for the future. And of course there's still plenty here that you can understand even without the number theory background. The book wants to be both a reference and a lesson-book. Nowadays, for the reference stuff, you'd probably search the web instead; in hindsight, it would have been nice if the book had concentrated on the lessons. Still, it's a fun read; check it out.

How to get programmers to get along together. Attempts to use psychology to design easier-to-use computer language features. Discussion of which is better for your organization's culture: batch processing of punch cards or time-sharing. Ahem, yes, that's right, I said "punch cards or time-sharing." This book is from 1971. Wow, that's even older than Peopleware. So it's interesting, but in sorta the same way as when you're reading Knuth and you're thinking "Wow, this book is so influential, I'm gonna learn a lot and--wha hey why is he talking about this weird non-Intel architecture OMG did people really argue about what the correct size for a byte is, I mean, c'mon?!?" Apparently, time-sharing was a not-unmixed blessing. If you get a bunch of geeks waiting in line to turn in their punch cards, sometimes they talk about useful stuff.

Yesterday, I watched a co-worker give a "practice" thesis defense. My workplace has plenty of grad students who are just, uhm, taking a little break from school. He's one of them. I, on the other hand, am the grizzled industry veteran who didn't go to grad school, was pretty darned glad to get out of school and into business where we learned really useful stuff like 286 assembly language. Uhm, whoops. Anyhow, this guy is presenting his thesis, and as part of it he gives a demo of some software. And I growl out "Working code? I thought you said this was a thesis." And I felt bad immediately--here's this guy working so hard towards an advanced degree, does he really need me making fun of the ivory tower right now? Probably not. Anyhow, he talks about what he's been working on, and it's pretty interesting and makes it pretty clear that he's had to done some new, clever stuff. And then he starts talking about how this research might be useful. And someone else in the room pointed out "Hey, it's a thesis--it doesn't have to be useful." And I'm sitting there thinking Hey he said it, not me and who said it? Another co-worker--but he's also a part-time lecturer at a local university's computer science department. Ah, academia. Folks cloistered away in search of knowledge; it can be awkward when they brush up against the real world. Which reminds me: I read Anathem and it was pretty good.

It's scary when you look at it--it has plenty of pages, more than plenty. But it flows quickly, the pages turn. There are ideas inside. You remember ideas, right? They're supposedly why we read science fiction. Far-out ideas, not just another space opera.

On the other hand, it seems cruel to discuss the ideas in Anathem since most of them are introduced as big Reveals. "Isn't it interesting, the idea of Soylent Green being cannibal behavior--reflecting the lessening value of human life..." So reviewers talk about the beginning, which shows us a universe in which a sort of Clock of the Long Now has set up clock/abbeys at places around the world, co-existing with a society somewhere between our own and a sort of tech-instead-of-magic Dying Earth.

I ended up disagreeing with the internal consistency of the book's premise. But I had to think about it. And it was fun to think about. And it's a fun book even if I disagree with the premise. Probably that's because the book isn't just about ideas. There are some fun characters running around in there, too. Towards the end, things seem like an action movie, but it's an action movie in which you care what happens to the characters--and also the action gets weird in places due to... due to ideas which I'm not going to discuss, lest I ruin the Reveal.

Fair warning: this book introduces some strange vocabulary. If you made it through The Book of the New Sun, you won't have trouble with this book. If you do have trouble with this book's vocabulary, be aware that there's a glossary in the back. At least, the edition I read had a glossary at the back. (And even if it hadn't, of course the internet would have come through with the info.)

Back in 2002, I went to the British Museum where an old illustration maybe showed a punch-card controlled loom from ancient China--long before such were invented in the West. Bookish fellow that I am, I looked for books on the history of Chinese looms. I hit a few dead ends along the way. One particularly massive dead-end was a huge, sprawling multi-volume work on the history of science and technology in China. "Multi-volume" doesn't do this thing justice. There were a lot of books, each of them heavy. It had a volume about silk cultivation in China, with promises of another volume, about silk weaving, to come in the future. But that future volume hadn't materialized, at least not that I could find. And yet this work had plenty of volumes.

I didn't have that set of books in mind when I picked up The Man Who Loved China, a biography of Joseph Needham. But I should have--Needham was the scholar woh organized and kick-started that massive multi-volume work. (Dieter Kuhn wrote the volume about silk-growing, but doesn't show up in this biography.) Chinese people, it turns out, invented a bunch of stuff. Nowadays, we know this. Back in Needham's day, we didn't know this. And by "we", I don't just mean European honkies. Plenty of people in China didn't know this about these discoveries--the local history of science was in scattered notes. Needham listened to a few Chinese scholars claiming that China had invented this or that--and decided to do some research. And encouraged other folks to gather their research. And put together a rather impressive piece of scholarship. Along the way, he ran into political trouble--China was a tricky political entity back then, and Needham was tricked into siding with China in a faked biowarfare attack--yes, really. There are interesting stories about his travels through China, done during the Japanese invasion. Interesting book, check it out.

It is Steve Wozniak's autobiography, as told to Gina Smith. It's a fun read. Keep your wits about you as you read--they didn't fact-check all of this material. So when Wozniak tells you what was going on in the industry at this time, you need to remember it was his perception. Probably everyone at Apple was saying that the Apple ][ was the first to sell a million units, so when Wozniak repeats this... Well, maybe that means that Apple was an echo-chamber around 1983, believing their own PR.

But it's worth reading this book. Wozniak has had a fun ride so far, and it's fun to read his reminiscences. Just in case you don't read it, though, I'm going to quote some things from the end of this book, the ideas he was hoping to convey, the lies he hoped to correct:

• He didn't drop out of college
• He wasn't thrown out of the University of Colorado
• He didn't go to high school with Steve Jobs (they went to the same school, but not at the same time).
• He designed the Apple I and Apple ][ machines himself, not with Jobs' help.
• If you are an inventor who works best alone, he advises you to work alone.
• If you are an inventor, please invent. We could use some better inventions.

I'll quote the last paragraph:

I hope you'll be as lucky as I am. The world needs inventors--great ones. You can be one. If you love what you do and are willing to do what it takes, it's within your reach. And it'll be worth every minute you spend alone at night, thinking and thinking about what it is you want to design or build. It'll be worth it, I promise.

Wow, inspirational stuff. I hope more folks are inspired by that than by some of Wozniak's practical jokes, many of which seemed more mean-spirited than funny. (Although I'm sure he would assure you that he didn't mean them in a mean-spirited way.) Check it out.

I posted that link to that "Another Bubble" video. Computer nostalgia is easy, you don't have to look back, the past just keeps coming back. That viper Wade Randlett who spread lies about the "New Economy" back during the Gore campaign (you remember the "new economy"--the bubble before the dot-com bust) is raising money for Obama now. How could Wade Randlett come back? How could he still be around? Not all of these people are still around. Some of them are still around. Chuck Peddle is still around. Chuck Peddle's not a viper, though. But he does get mentioned in the book On the Edge (by Brian Bagnall), as you might expect--this book is the story of Commodore Computer, and Peddle was the main designer on the 6502 chip. This book was a lot of fun.

I enjoyed this great moment in the history of technical documentation:

The [MOS 6502] microprocessor would be useless to engineers without documentation. Peddle recalls, "We were coming down to launching and my buddy [project manager-ish Petr Sehnal] kept telling me, 'Chuck, you've got to go write these manuals.' I kept saying, 'Yeah, I'll get around to it.'" Peddle did not get around to it.

With Wescon rapidly approaching, and no manual in sight, Sehnal approached [boss] John Pavinen and told him, "He's not doing it."

"John Pavinen walked into my office with a security guard, and he walked me out of the building," recalls Peddle.

According to Peddle, Pavinen gave him explicit instructions. "The only person you're allowed to talk to in our company is your secretary, who you can dictate stuff to," Pavinen told him. "You can't come back to work until you finish the two manuals."

Peddle accepted the situation with humility. "I wrote them under duress," he says. Weeks later, Peddle emerged from his exile with his task completed. The 6502 would have manuals for Wescon.

I'm a technical writer. I've worked with many engineers. About 25% of engineers can write great documentation no problem; about 50% can muddle along. And then the other 25% of engineers... can't muddle along. I guess that's been a problem for a while.

I grew up with Apple ][ computers. I always thought that Apples were more popular than Commodores. This book says that that was a lie--well, eventually Apple overtook Commodore, but had claimed to be #1 long before that.

Engineer Bil Herd passed along a fun story about physical security, policy, and reality:

A few weeks before CES, Herd began running into unforeseen obstacles. "The security guards started locking the door," recalls Herd. "They got a rule that said all lockable doors should be locked on Friday nights. So Saturday I walk in, and I can't get in my office. There is no key for this door because it's new construction, and the contractors haven't dropped the keys off yet."

With the deadline near, Herd decided to go around the problem. "I had to get back to work," says Herd, "You can't keep me from working. So I climbed over the ceiling and got all gucky doing it, and cut myself, but I opened the door and got back to work."

To prevent the incident from reoccurring, Herd posted a friendly notice on the door. "I put up a sign that said, "Please do not lock this door. There is no key for it," he recalls. " Well they locked it again. We went through three layers of notes. The first one was real polite, the second one said, 'Look, you locked it again. We can't get in to do our jobs. Don't lock this door, there is no key.'"

Herd thought his notes explained the situation clearly, but the instructions from management overruled Herd's pleas. "Well, it got locked again," says an exasperated Herd. "Somebody came and got me and said, 'I can't get in the room. It's locked again.' This is the room they had given me to do the project, so it's my room as far as I'm concerned."

Herd stormed towards the locked door in a rage. The previous times, he had gone around the problem. Now he decided to go through the problem. "I punched a hole through the wall to where you could reach in and unlock the door," recalls Herd. "I just barely missed a light switch on the other side, which would have split my knuckles wide open."

Herd thought the faceless battle of wills had come to a climax, but it continued. "They locked the door again!" says Herd. "You had to reach through the hole to unlock the door and you would get your arm all chalky and everything. Finally, I had to write a note that said, "Look, assholes. There's a fucking hole in the wall next to the door. You can stop locking it now."

I liked this comment, though I think many readers might think it requires some explanation:

One powerful feature that distinguished the Amiga operating system from the Macintosh was the Command Line Interface (CLI). This allowed users access to powerful DOS commands using command line arguments.

I learned that chips for the NES system were basically tweaked 6502s, just changed enough to dodge patents.

This is a wonderful book to read. It's long--Commodore tried many computer projects, and this book discusses many of them. It jumps forward and backward in time to cover the various arcs. But there are plenty of cool little anecdotes and strange characters. Check it out.

I'm not working on gPhone the Open Handset Alliance. There were various internal recruiting drives for the project; I slunk away from those, kept my head down. I've worked on some mobile phone platforms. Lately, I've been working on other things. Mobile phones were interesting, but it turns out that these other things are pretty interesting, too. Still, there are memories.

The first of those mobile phone platforms was made by a company called Geoworks. Ah, Geoworks. The name brings back waves of nostalgia. But it's a rue-tinged nostalgia. Like, there's some rue mixed up in that first mobile phone platform. It was pretty advanced, it ran pretty fast, seemed to be engineered better than the competition. But then all of the deals went away. A competitor had turned their platform into a standard which many companies would contribute to--an alliance, as it were. In the end, most of those allies didn't use the software, but it took those allies a while to figure out what they would do, software-wise. Meanwhile, they sure weren't buying Geoworks' software. Eventually, most of those allies fell away from the alliance; Is Nokia the only one left? Anyhow. That alliance was Symbian. Recently the CEO of Symbian was described in the news as not being too worried about the Open Handset Alliance. Was he really being disparaging--or does he know how hard it is to keep an "alliance" of mobile phone companies to cooperate?

Ah, Geoworks nostalgia tinged with rue, woven through with rue.

GEOS didn't start out as mobile phone software. It started as an OS for x86 machines. You know, PCs. Microcomputers. Going up against Microsoft? What could we have been thinking? Which reminds me: I am supposed to be writing this book report on the book In Search of Stupidity. (This might be a good time to mention that my opinions are mine. My opinions are not my employer's. My opinions are not my now-defunct ex-employer's--any of them.)

Joe M. at work recommended this book. It has some fun anecdotes from the early days of microcomputers. Back when PCs were called microcomputers. Back when all PCs were not necessarily called "PCs". Anyhow. I liked it plenty. Then again, I am a geek of a certain age and thus remember some of the products described. The book's theme is marketing blunders. But (as noted in an afternote), it's hard to narrow blame marketing for all of these blunders. In one anecdote, the company fires all of the engineers... and has trouble marketing future updates. Is that bad marketing?

The most flattering part of this book is in the chapter on OS/2. It talks about how plenty of software companies wasted plenty of effort to port their software to this OS... to no benefit because that OS never really took hold. That wasn't the flattering part. What was the flattering part? The book, a book about stupid companies, mentions my old employer Geoworks, but does not call it out as a stupid company. Yay.

At this point, IBM still had the ability to checkmate Microsoft's plans for Windows. One way was to buy a new OS from a company called GeoWorks. The company had developed a highly optimized product with a slick GUI that could run in a small hardware footprint; GeoWorks ran with amazing alacrity even on the original IBM PC. This was the path favored by [IBM's] Desktop Software division.

The book doesn't mention that Geoworks actually worked on implementing the Presentation Manager look and feel on top of GEOS. (I'm probably getting the details wrong there. But we were doing something like that for IBM.) The theme of that chapter in the book is Companies that IBM Tricked Into Wasting Effort on Presentation Manager and OS/2. I think IBM paid us for our work, though. If we were getting paid, that means our effort wasn't wasted, right? I sure hope so. I think the main lesson we learned was: Never work on a project codenamed "Wizard". It's always bad news.

What, the book? You wanted to hear about the book? Oh, the book is good in some places, other places you might want to skim. The best places are the first-person anecdotes. The author, Rick Chapman was employed with some kooky characters at some of these early microcomputer software companies. Reading about them... you just can't look away from the trainwreck.

I like old computers. This is a book of photos from the Computer History Museum. The photographer, Mark Richards, gave a talk at work a while back. When people asked him how he chose which things to photograph, he said that some was aesthetics--but some was placement of machines within the museum. No-one was going to move one of these devices just so that he could get the photo he wanted. If you've been to the Computer History Museum, you might remember that there are some support columns scattered around that block your view. As a limber human, you can crane around and eventually get the big picture of what something looks like. But the camera doesn't have that option. The photos are stunning; some are on the internet.

Lea W. is in town, visiting from Cincinnati. Several folks gathered at Yancy's Saloon on Irving to kick it with Lea. Michael asked the question: "What do you love to do? There are a bunch of things that you like to do, but what do you love to do? What do you look forward to all the time?" Michael used to love basketball, until his back got messed up; now he loves travel. Eiko likes to run on trails, then eat protein-rich meals while talking with friends. I said that I loved to play puzzle hunts; then when someone said that she loved to sail, I thought that I wanted to change my answer to sailing; then I wanted to change my answer to travel. But I don't think any of those things are it. I left the party early. I was sleepy. I am sleepy. But still I'm thinking. I was thinking on the way home. I was thinking: I don't love any of those things, but I love writing about them afterwards. But that wasn't quite right. And then I thought, I love doing things with family and friends. But that's not quite right either--I love traveling, love writing about traveling, but that's often alone.

I think it's this: I love looking forward to having a story to tell. I love to do fun things with family friends because then we can reminisce about them later. I love to do things I can write about, because that means that there's a story in there, and I can tell that story to people and they'll like it. It's too bad that most things in life don't result in stories. Or maybe they do. I was just reading a biography of a Silicon Valley pioneer. It wasn't much like my life, but it wasn't so far different. Anyhow, this book, The Man Behind the Microchip was pretty interesting.

I've worked at start-ups. I felt like a pioneer, doing something new. But I shouldn't have. Start-ups are old news. This biography of Robert Noyce, an electronic engineer from the early days of semiconductors and microcontrollers, is full of start-up stories. They brought back memories, some of them painful. I thought I was breaking new ground, but this was all well-trodden.

But why talk about the personal stuff? There's plenty of other echoes here. Or rather, this book points out that present-day events are echoes of the past. It was big news when Google recruited people by posting puzzles on billboards and in magazine ads. But here's a little snippet about Shockley Semiconductor:

Vic Grinich, tall and thin with curly hair he wore longer than the fashionable buzz cuts, responded to a want ad that Shockley had written in code an published in a scientific journal to screen out insufficiently intelligent applicants.

Nowadays, electricity is a big factor when planning a computer service that's going to scale. You don't want to plan on building machines that you can't afford to power up. Apparently, this is a revival of a 70s concept, back when OPEC was standing firm on an oil embargo.

The prospect of rolling blackouts alarmed Noyce, who readily admitted that the semiconductor industry had designed its processes and equipment "assuming that petrochemicals were free and available and that power was free and available." The average wafer fab used 30 times as much electricity as a commercial office building of the same size, and consumed large quantities of xylene, acetone, and disopropyl alchohol, all petrochemical derivatives.

Nothing new under the sun; we stumble in the footprints of giants.

Tags: books | Moore | Grove |

Sometimes, it's good to be wrong. For example, I claim to be pretty jaded. But when I saw a little dog, a Yorkshire terrier-style dog, walking along this morning carrying a rubber chicken, I was filled with joy. I would have thought I was too blasé to enjoy such a thing; I was glad to be mistaken. For another example, there's Xerox PARC.

There's plenty of Xerox PARC myths floating around and I fell for most of them. Until I read this book by Michael Hiltzik, which does a good job of squooshing the history of a far-ranging computer research lab into something resembling a narrative.

Anyhow, I'm quoting this bit from the introduction as a myth-debunking public service. But if you want the details, you should read this book.

...That Xerox proved only sporadically willing to follow them is one of the ironies of this story. The best-publicized aspect of PARC's history is that its work was ignored by its parent company while earning billions of dollars for others. To a certain extent this is true. ...

Yet this relationship is too easiy, and too often, simplified. ... Xerox was so indifferent to PARC that it "didn't even patent PARC's innovations," one leading business journal informed its readers not long before this writing--an assertion that would come as a surprise to the team of patent lawyers permanently assigned to PARC, not to mention the center's former scientists whose office walls are still decorated with complimentary plaques engraved with the cover pages of their patents... Another business journal writes authoritatively that the Alto "failed as a commercial product." In fact, the Alto was designed from the first strictly as a research prototype--no more destined for marketing as a commercial product than was, say, the Mercury space capsule.

Another great myth is that Xerox never earned any money from PARC. The truth is that its revenues from one invention alone, the laser printer, have come to billions of dollars--returning its investment in PARC many times over.

Along with all of this myth-busting, this book showed me something scary. As Xerox was ignoring plenty of computer innovation and sticking to copiers, it thought of itself as a high-tech company. Executives didn't think of themselves as manufacturers of boring office equipment. They thought they were cutting edge; they did not handle it well when other companies caught up with their copier technology. That felt familiar. Just because everyone at your company tells each other, "We're working on cutting edge stuff," you might all be pulling the wool over each others' eyes. Of those companies beating dead horses, few of them have employees who say, "We had our last great idea ten years ago." (Disclaimer: my snide remarks about faux high-tech companies are my opinion, and not those of my employer. Heck, if my employer turned cut-throat, my employer would probably be glad for the self-delusional mindset of some high-tech companies... but I digress.)

Thanks to Piaw's blog for pointing me at this book.

Tags: book | legends | giant shoulders |