Customer Reviews

I Sing the Body Electronic: A Year With Microsoft on the Multimedia Frontier

5 star:		(6)
4 star:		(7)
3 star:		(3)
2 star:		(0)
1 star:		(1)

 

 

So many of the books about software development I have read are about an organized, heroic march from conception to delivery. This book is a much more realistic depiction of the chaos and mess that most people actually live with in real world software development. Moody did a good job of just telling the story and not judging the messiness or trying to clean it up to create the typical late night, pizza boxes and Jolt Cola heroic story. He does a good job of discussing the complex human issues surrounding the project and their importance relative to the actually technical issues. Creating the technology turns out to be relatively simple compared to the challenge of getting a group of people from very diverse backgrounds to function effectively as a team. This challenge is particularly strong in consumer technology products because the range of backgrounds required is so broad. The communications and collaboration skills needed to allow artist and programmers to work together are insightfully revealed in this book

As mentioned in the introduction, you could read this as a story of success or a record of failure, depending on your focus. The Sendak/Explorapedia was released a year late, overbudget, and did not meet the original design objective of a complete multimedia children's encyclopedia on one CD-Rom. On the other hand, it actually did meet the original estimated release date, and it went on to become a best seller and a benchmark in it's category.

Actually, I think Fred Moody missed seeing the real benefit to Microsoft of the Explorapedia project. While Moody focussed on chronicling the damage created by the personality conflicts and differences in communication styles, he missed seeing the positive consequences of tackling a project like this which pushes the envelope of existing technology.

For instance, here is my take on two of the "problems" described by Moody:

1: In the beginning, there was no software developer assigned fulltime to the project.
Positive result: The designers, who were mostly Mac people, designed the encyclopedia to use Mac-like features, such as sprites with transparent backgrounds. This was not available on the PC at that time, but the positive end result is that when the PC designers finally started work on the encyclopedia, they were forced to come up with solutions that emulated Mac-like graphics features on the PC, solutions which inevitably expanded the capabilities of the PC and brought it closer to the Mac graphics benchmark.

2: Software tools such as Merismus and SPAM were not fully available when the project started.
Positive result: This may be the largest contributor for the project's slipped schedule, but the benefit of developing the tools concurrently with the application is that the development of tool features is driven by the immediate needs of the innovative application. Otherwise, the Merismus and SPAM tools would probably have been developed looking backwards to the Encarta project, as in "gee, Encarta would have been a lot easier to do with this tool." Instead, motivated by the needs of Explorapedia, the new tools were driven towards making succeeding generations of software easier to develop, rather than preceding generations.

Applying this to my field, hardware development, it illustrates the value of starting a project even if, in the beginning, it does not appear to be feasible within the current state of the art. After all, somebody has to define the state of the art; it might as well be your project. And the shape of a new tool cannot be defined until you know the size and shape of the problem it must solve. Also, as with Mac graphics on a PC, it helps to have a target to shoot for, and the knowledge that it's been done before.

To be critical of this book, I would say that a lot of Moody's focus is on communication conflicts: the analytical developers don't value the artistic designers, the women don't manage conflict like the men do, the permanent employees dismiss the contract workers. Another author, Deborah Tannen, has covered this ground with more insight, and Moody's descriptions of conflict between individuals are much easier to understand when reviewed from Tannen's point of view. For the most part, Moody settles for a gossipy telling of all the dirt that went on between people, with little revelation for what caused the conflicts, how they might have been avoided, and why the project succeeded in spite of those challenges. In the end, his revelation is that the project teams are deliberately given impossible goals by Bill Gates, with the intent that every team member, perceiving his last project to be a failure, goes on to other projects with the idea that they must work extra hard to overcome the stigma of that last failure. I doubt that even Bill Gates is that Machiavellian.

THe best book! Makes you feel comfortable if you are new working in a software development job. And how software development basically involves dealing with different kinds of people. ANd all the extremes in personality of the programmer. It also describes the rare and challenging lifestyle that the programmer pursues and chooses...

The real value in this book is the great work that Fred did to get inside the development team, and then observe. I've worked at R&D in Microsoft for long enough to know that he probably is telling it largely as it happened. I didn't work on this project but I got pretty damned close.

Yep, it sometimes is that chaotic. It's interesting to see in the book how Fred doubts himself, and says things like "maybe I'm going crazy, but it seems like these people just had another useful offsite, but they all think it went great." Fred, you ain't crazy.

The only drawback of this book is that in places Fred tries to read into situations a bit too much. He steps a little too far out of the observer role a few times, which brings the quality down a bit. Also I think he missed a great opportunity to describe the turn-around (well at least they shipped something) at the end. Maybe he got kicked out around then?

The book has lots of direct quotes and first hand accounts of what went on. Want to see the dark side of things going wrong at Microsoft?? Read this book.

In the past I always assigned "Soul of a New Machine" to show my students what it's really like to work in a small project team with unrealistic deadlines (i.e. normal high tech). But the technology there is too out of date - 4.77Mhz, single boards for single functions, etc. So I have shifted to "I Sing," with generally good results. The book is 2x the length I would like so I assign selected chapters, but it reads easily enough that most students read the whole thing. They are always amazed by the level of chaos and conflict; in fact it makes them feel better about their own team design projects. The sequence of events is not easy to follow, there are too many characters, etc. so I provide some supplemental information on my web page. This is the best book I know of for a class on high tech development culture. There are plenty of case studies of the auto industry, but most of them are puff pieces and they are all about giant projects. Ditto for books about Boeing. The e-commerce stories are polluted by money and novelty issues (though I keep hoping to find one.)

This book from 1993 to 1995 is a depressing view of the inside of a multimedia project run by young, Generation X Microsofters who sincerely believed in the company vision. Although, with a company that large, that diverse and that disorganised, I think the vision couldn't be seen for the re-organisations.

The book follows a group of 20 somethings from the initial ideas of the multimedia project (called Sendak until it's official name of Explorapedia was chosen,) through to almost the delivery stage. And there are two over-riding themes that contribute to the almost failure of the project: unclear lines of control, and indecisiveness.

Let's look at these in turn.

Production Manager, Project Manager, Art Director, Lead Programmer and Chief Coffee Maker. (Okay, I make that last one up.) Throughout the multimedia project detailed in this book, the roles people undertook always seemed to be fluid in their meaning and responsibilities. One reason for this was that, as Microsoft was growing so fast, internal people were often promoted over external hires and so some quite young staff ended up in fairly senior positions. People who once worked as equals, were now supervisor and the supervised. Which might not be a bad thing, but without the proper training, could be quite catastrophic in the personal and professional relationships of all those involved. Here, this was experienced as the previous Art Director on another project was now the Producer (or the other way around, or the Production Manager - I should have taken notes while reading it,) and it wasn't always clear who had what responsibility. So, one person was sometimes butting in and doing the other's work, and as the project went on, there would be re-organisation after re-organisation which lead to mass confusion about who exactly the decision makers were.

We trained hard, but it seemed that every time we were beginning
to form up into teams, we would be reorganised. I was to learn later
in life that we tend to meet any new situation by reorganising; and
a wonderful method it can be for creating the illusion of progress
while producing confusion, and demoralisation.
-- Petronius Arbiter, 210 B.C.

It just seemed to be the Microsoft Way.

The other problem with this project was the scope of what was being produced. The clearest voice of reason in all of this was the cranky programmer, who knew quite well when things had to be decided, and not changed in order to have the code finished and tested to meet the ship date. The programmer, as one of the final steps in the design and development process, always appeared to be the one that had slipped and missed their milestones, rather than the designers who had missed their deadlines at the beginning of the project because of an inability to make a decision, and stick to it.

And here's where the traditional Project Management Methodology and also Agile Project Management Methodology can fail: once a decision has been made, even though it's software, it costs a lot to go back and re-engineer something. This project almost failed because the scope was a wibbly-wobbly thing that the team never really got a hold on, wrestled to the ground and took control of. As such, late in the design and early development stages, fundamental changes were introduced that changed the game (literally.)

So, what can be learned from this? Make sure that the client (even an internal client) knows that a change in scope means changes in time and cost. It's an immutable law of Project Management, and I know we all know it, but sometimes we need to state the obvious. Also, experience pays off - in software development most people are in their 20s, and now that I'm not any more, I can look back and see how inexperienced I used to be, and how much there really is to learn about process management.

The project shipped, many people were burnt out, angry, demoralised and just plain over it. But in the end, as we all know, we just get back up again and walk into the maelstrom for one more go, because we believe this time it will be better - it just has to be,

Finally, one criticism of the book: I kept getting lost with regards to who was who. Sometimes the author would use a person's given name, and then later in the book, their family name, and then back again. So, as people changed positions, I didn't know who the Project Manager was from the Producer to the Production Manager. It's a small quibble, and really in the end it doesn't distract from the book.

Have you ever wondered how the teams at Microsoft work? This book is an inside glimpse into how a work group there operates. It is not a comprehensive view of Microsoft and in fact each group could be said to have its own unique dynamics, but this book will provide a brief and useful view of the process of creating and shipping a product at Microsoft. This book follows several members of a group within a now defunct section of Microsoft. They were creating a product, and the book documents each persons feelings, opinions, and unique perspectives on getting their own jobs done and how they have to work together to accomplish the ultimate goal of creating a product. Microsoft employees, it is shown, have a great deal of personal freedom and latitude in doing their jobs, but when it comes to working together in a team, their very idiosyncratic personalities often conflict. Add to this a very strange but not surprising element of artists versus programmers versus project managers. Add yet more regular Microsoft employees versus contract employees. Whether the friction and problems the book conveys are real or not, they are perceived by many employees, which affects the work environment. An interesting aspect of the business model and organizational chart is that the employees are only a few levels (3 or 4) away from Bill Gates (or the highest level of the company). Most people at some point in their careers are required to present their work to Gates (or equivalent level) at some point. The book depicts Gates as a very temperamental and demanding person who will look at something which is next to perfect, get angry about its flaws, and yell at the creators insisting on something much better. And then when the presentation is over and the creators leave, Gates says something about how brilliant it was, but if people think he did not like it, they will strive to make it more perfect. The book might be dated by now. Organizations change a great deal in just a few years. Microsoft was not being threatened by the Justice Department when this book was written, and although MS was a huge company then it was not as big as it is now. The book is the first to point out the effects of organizational change, and Microsoft, like most large companies, goes through organizational change frequently. Interesting book... worthwhile read.

"I Sing the Body Electronic" is a success story. Fred Moody entertainingly describes the lifecycle of a product created by Microsoft. The mystifying part is how the success described in the story came to be. Moody vividly explains the socio-political inner workings of Microsoft by tailing a development team from the start of a product until its eventual completion. The team members come to life on the page, and the observations made by Moody add an intellectual quality to what would otherwise be a soap opera.

The book is gripping until the very end. The dialogue and writing are easily read, and well chosen. The chronological layout of the book, while necessary, is unfettering. All together the book is well written. Fred Moody ends the book with a provocative suggestion as to how a doomed project became a success. I wont spoil it by telling you what it is, but trust me its insightful.

I can't help but believe that Bill Gates traded in his families only possessions for some magic beans. Well it has certainly paid off for him, and Mr. Moody as well.

On one level this is a fascinating and often surprising inside look at the world's leading software producer. On another, broader level it is an equally fascinating account of a talented group of artists, editors, producers and programmers who set out in late 1992 on a mission to create a standard-setting, financially-successful new product (a multimedia encyclopedia for young children) in a newly emerging and as-yet-unproven field (multimedia computing) of an industry characterized by intense competition and constant change. The author does a great job of conveying the personalities, goals and emotions of the varied team members, and the often frustrating, sometimes hilarious interplay between artistic and technical mind sets, between vision and implementation.

Very few detailed accounts of software projects are written skillfully, dispassionately and with deep understanding of the subject. Mr. Moody's book belongs to this small group. Aside from the disappointing Postmortem chapter, which is not a real analysis, but a feel-good ending note, Mr. Moody's work is a very worthy read. The author is an acute observer and a first-class journalist.