Saturday, December 02, 2006

Books It's been a while since I've posted on the books I've been reading.  Here's a list of what I've read lately (Not in any particular order): 51.11 - Product Development for the Lean Enterprise (Michael N. Kennedy) 51.12 - Corps Business (David H. Freedman) 51.13 - The Art of Project Management (Scott Berkun) 51.14 - Monday Morning Leadership (David Cottrell) 51.15 - Shocking Velocity! (Srikanth Srinivas) 51.16 - Management of the Absurd (Richard Farson) 51.17 - 12 Choices... (David Cottrell) 51.18 - Project Management (Peter Hobbs) 51.19 - Insights for the Journey (John Lucht) 51.20 - The One Thing You Need to Know (Marcus Buckingham) 51.21 - Implementing Lean Software Development (Mary & Tom Poppendieck) 51.22 - The Toyota Product Development System (James M. Morgan & Jeffrey K. Liker) 51.23 - Toyota Production System (Taiichi Ohno) 8:47:28 PM    comment []

Back again... I repaved my computer when Vista RTM was available on MSDN and I've been putting off moving Radio to the new OS.  Today I finally got it going... 5:58:00 PM    comment []

Sunday, August 13, 2006

51.10 - The Polaris System Development (Harvey M. Sapolsky) This book came to my attention at one of NetObjectives' recent free siminars.  Alan Shalloway was giving a talk on Lean development and brought a bunch of related books that he let us browse after the seminar was over.  More recently, Dave Smith mentioned it on the AYE Wiki.  I went to Amazon and found that the book was out of print.  It was available used for $229.67 but I can't pay that much money for a book.  So I sent an email to the Microsoft library.  They didn't have it but were able to get it on inter-library loan from the University of Washington.  Since reading this book was now time-bound, I paused my reading of Scott Berkun's book to read this one. This book is the result of in-depth research into the Polaris System project.  This objective of the Polaris project was to create a submarine-based ballistic missile project (the Fleet Ballistic Missle Program or FBM) in the shortest possible time.  It has been pointed to as an example of an extremely successful project.  It came in early and hundreds of millions of dollars under budget.  Sapolsky was asked to prepare a report on it and obtained permission to publish the report with no review other than for security purposes.  The book was written in 1971, 35 years ago. The book starts off by setting the context for the project.  It was the late 1950's and Sputnik had just happened.  America was worried and the various branches of the armed services were all vying to produce an ICBM system.  Soposky does a good job explaining the political manuvering that the leaders of the project had to do in order to get permission to build the system.  Sapolsky talks about four bureaucratic strategies that were used to help make the project happen.  The strategies were: Differentiation - establishing unchallengable claims on valued resources by distinguishing their program from those of their competitors. Co-optation - absorbing new elements into its leadership as a means of averting threats to its stability or existence. Moderation - building long-term support for their program by sacrificing short-term gains. Managerial Innovation - the attempt of an organization to achieve autonomy through the introduction of management techniques that appear to indicate unique management competence. The organization of the Navy at the time the project was getting started was composed of 2 groups: the technical bureaus (responsible for material resources) and the operations staff (responsible for determining weapons requirements).  The proponents of the Polaris project set up a special group, the Special Projects Office (SPO) separate from the regular Navy organization that would have complete authority over the project.  Not everyone in the Navy was happy with that idea.  The SPO had to be skillful and make compromises in order to be able to do what it needed to in order to successfully execute on the project goals.  One thing that is stressed in the book is that the bureaucratic strategies that were used did have an effect on the program itself but they were needed to give the program a chance to exist. Item #4 in the list above (Management Innovation) is very interesting and a whole chapter is devoted to it.  Note the words "appear to" in the description.  New management techniques used in the Polaris project, including the widely-known PERT, were credited with the success of the Polaris project.  So successful was the promotion of PERT and the new management techniques that an industry sprang up to provide PERT tools to all businesses so they could have the benefits of these management innovations. The trouble was, those innovative management techniques were found not to be responsible for the success of Polaris.  Politically, though, it was in SPO's interest for the world to believe that the benefit of using PERT was the reason for Polaris' success.  As Sopolsky writes: "It was a myth, however, that had value.  For those who wanted the FBM submarines developed, but were reluctant to place their faith completely in the men assigned the task, it gave a sense of assurance.  The management system, not the men, would guarantee the development of the Polaris.  For those who were developing the Polaris, it removed the necessity of justifying each development decision to a higher authority." So, what was the real reason for the success of the Polaris project?  According to Sopolsky, careful management of the interfaces of the components of the system and competition for the job of implementing those components.  Sopolsky talks about "maxims" that were used by the top manager for the project. Performance requirements for the system should be set by the technical director of the project along with those in the project who were knowledgeable in the relevant technologies. The program's objective was the construction of a deployable system and not the advancement of technology.  All technical tasks other than those contributing directly to the deployment of a submarine-launched ballistic missle should be avoided. Naval laboratories were not to be used in the development effort unless they posessed a technical competence unavailable in private organizations. Focus on high quality was another important part of the success of the effort; "Reliability and methods to achieve it became program fetishes." The book continues with an examination of the costs of the program and a look at how the program changed as Polaris drew to a close and its successor, Poseidon ramped up.  The tone isn't optimistic. The final chapter reviews the elements that led to success for the project.  These include: A favorable environment - there was immense national support for the mission of the Polaris project. Skill in bureaucratic politics - The leaders of the Polaris were deft in this area and able to protect the project from outside risks in this arena. Ability to manage technical complexity - disciplined flexibility, decentralization, and competition worked extremely well on this project and may be the best way to manage large development projects. This was an excellent book and well worth the extra effort I had to go through to find a copy.  Reading about this 35-year old project didn't feel dated at all.  Consider all the recent large development projects you've heard about.  Any of them coming in early and under budget?  Maybe they could learn some lessons from the Polaris project. 8:59:45 PM    comment []

Tuesday, August 01, 2006

Next up.... 51.9 will be The Art of Project Management. 11:01:54 PM    comment []

Thursday, July 20, 2006

51.7 - Death by Meeting (Patrick Lencioni) Another day, another Patrick Lencioni book.  So far every book I've read by Lencioni has taken me one day to read.  Fast.  In, get the story, a bit of the theory, and out. Death by Meeting's story is engaging if a bit, how shall I say it, contrived.  The wise young helper just happens to have a Tourett's like condition that causes him to blurt out the uncomfortable truth at inopportune moments (which also helps to push the story along).  I get it, it's cool. But the model is a good one.  Meetings in general do suck.  And most people think the right thing to do is get rid of them.  Lencioni disagrees.  Well, he agrees that most meetings suck but, from his point of view, it's because we don't do them right.  And he has a model for how to do them right. He proposes four types of meetings: 1. Daily 5-Minute Stand-up 2. Weekly Tactical 3. Monthly Strategic 4. Quarterly Offsite The book goes into detail about each of these meetings and why you'd structure your suite of meetings this way.  It makes sense to me. In my own situation, the meetings that seem like they will work well are the weekly tactical and the monthly strategic.  I'm going to try changing my meetings to use those ideas and see how it goes. 12:45:56 AM    comment []

Sunday, July 16, 2006

51.6 - Blink (Malcolm Gladwell) Malcolm Gladwell's book Blink has been quite popular for a while now.  I finally got around to reading it recently.  Although I have a built-in predisposition to not like things that are popular, I really liked this book. Blink talks about a phenomenon called "thin slicing" which refers to the decisions that we make without a lot of deliberation.  I'm familiar with this, having read a couple of books by Gary Klein.  Klein does research in this area and is referred to in Gladwell's book.  Blink fleshes this idea out more broadly with many compelling stories that show thin slicing in action. The stories Gladwell recounts show the power of thin slicing but some also show the limitations.  One thing Gladwell also points out is how thin slicing can be made less effective by over analysis.  This is something I thought was important to be aware of. I was talking about blink with a colleague of mine this week and one point he made is that this book doesn't tell you how to get better at thin slicing (perhaps another aspect of over-analysis weakening it?).  I didn't really pick up an explicit mention in the book of how to do this but I did notice some similarities among the stories in the book.  In all cases, it seems that spending time in the domain gave people thin slicing power.  For example, in dissecting the Pepsi challenge, Gladwell notes that when average people are given 3 cola samples they aren't able to identify which are Coke and which are Pepsi.  When professional taste testers do the same exercise, they nail it every time. What I gained from reading this book is an awareness of the power of thin slicing, an appreciation of the importance of context in applying it, and a confirmation of my idea that domain expertise is one aspect of excellence in a particular area. 11:22:26 AM    comment []

Saturday, July 08, 2006

51.5 - How to be Creative (Hugh MacLeod) I have a friend named Phil.  Phil is a drummer but worked at Microsoft for a long time (longer than I've been at Microsoft) in developer support.  A few months ago, another friend of mine and I got together for lunch with Phil where he told us he was leaving Microsoft.  He was joining a band that was going on a long tour all over Europe. We talked about a number of things that day and one thing Phil mentioned that meant a lot to him and helped him decide that it was time for him to put music first in his life was a post called "How to be Creative" from a weblog by someone named Hugh MacLeod. How to be Creative is a collection of 31 short essays on various ideas related to creativity.  The basic ideas center around themes like: Trust yourself Don't be impressed by popularity Do the work etc. I go back and read this web page every so often to remind myself of these ideas.  You should too. I haven't talked to Phil since he left for the European tour.  I did get an email with a photo of him standing in Red Square in Moscow.  He looked happy. 7:50:16 PM    comment []

51.4 - Silos, Politics, and Turf Wars (Patrick Lencioni) This book follows the familiar formula Lencioni uses in his previous books.  Well.. at least the same one used in The Five Dysfunctions of a Team, the only other book I've read from this author.  It's an effective formula. The lion's share of the book consists of a fictional story (referred to here as a fable) meant to illustrate the problem that the book tackles and the proposed solution.  Following the story, the principles of the solution are explained (referred to here as the theory). In this particular instance, the problem that's being tackled is that of the different parts of an organization operating separately from and, often, at cross purposes of each other, making the organization as a whole ineffective.  Lencioni proposes a model for approaching the problem that is simple to understand.  The model came from noticing that a lot of the ineffective ways of operating disappear when the organization is in a clear crisis.  But why do most organizations have to wait for a crisis to get to the point of eliminating the non-productive behaviors? This book was very engaging and easy to read.  I finished it in less than a day.  Not a bad investment for the benefit I feel I got from reading it. 12:33:55 PM    comment []

Thursday, July 06, 2006

51.3 - The Design and Evolution of C++ (Bjarne Stroustrup) This book is copyright 1994, the year I started working in Developer Support for Visual C++.   I'm a bit embarrassed to admit that I haven't read this book before.  Since I've decided to add more C++ books to my reading queue, I thought I'd start with this book.  I'm glad I did. My general impressions after reading this book are that C++ was really crafted from real user experience by someone who had strong ideas of what the language should be (and should not be).  Those ideas make a lot of sense even 12 years later and I think that's one reason why the language endures.  Some stuff from the book that surprised me or that I didn't know and found interesting: The initial incarnation of what would become C++ (C with Classes) contained a feature that would allow you to specify a function that would be called before every member function call and another that would be called before every member functrion returned. Almost from the very beginning, C++ has had a community of users that had to be considered as the language moved forward. Andrew Koenig and Barbara Moo were the test team for C++ version 2.0. Stroustrup wrote this with respect to what C++ is suitable for: "C++ is not ideally suited for applications that do not have major systems-programming components and where run-time and space efficiency requirements are not demanding.  However, when supported by libraries and possibly by a garbage collector C++ often is a viable tool."  As far as C++ strengths, he mentions low-level and higher-level systems programming, embedded systems, numeric/scientific computing, and for certain components in mixed systems. Back in 1994, Stroustrup expressed the desire that C++ implementors take the language beyond text files and character-oriented tools. Multi-methods were consdered for C++ and Stroustrup expresses regret that he was unable to get them into the language. D&E is an excellent book full of great information and history about the evolution of one of the most important programming languages in history.  I'm glad I finally got around to reading it. Recommended. 12:24:07 AM    comment []