Erik on Software

Success and Failure

If you set your goals ridiculously high and it's a failure, you will fail above everyone else's success.

- James Cameron, The Return of James Cameron

Personal Reading List: 2Q2010

My personal reading list for April, May, and June 2010.

Color Key: Special Notes, Currently Queued,  Completed Reading.

---

 Bridging the Silos: Enterprise Architecture for IT Architects, by Tom S. Graves, Tetradian Books, 2008.

Callous Disregard: Autism and Vaccines - the Truth Behind a Tragedy, by Andrew J. Wakefield, Skyhorse Publishing, 2010.

The Data Model Resource Book Volume 1 (Revised Edition): A Library of Universal Data Models for All Enterprises, by Len Silverston, John Wiley & Sons Inc, 2001.

The Data Model Resource Book Volume 2 (Revised Edition): A Library of Universal Data Models by Industry Types, by Len Silverston, John Wiley & Sons Inc, 2001.

The Data Model Resource Book Volume 3: Universal Patterns for Data Modeling, by Len Silverston and Paul Agnew, John Wiley & Sons Inc, 2009.

 Five Germanys I Have Known, by Fritz Stern, Farrar, Straus, and Giroux, 2006.

Healing the New Childhood Epidemics: Autism, ADHD, Asthma, and Allergies - The Groundbreaking Program for the 4-A Disorders, by Kenneth Bock, M.D. and Cameron Stauth, Ballantine Books, 2007.

IBM and the Holocaust: The Strategic Alliance between Nazi Germany and America's Most Powerful Corporation, by Edwin Black, Dialog Press, 2009.

Java Transaction Processing: Design and Implementation, by Mark Little, Jon Maron, and Greg Pavlik, Prentice Hall PTR, 2004.

Never Pure: Historical Studies of Science as if It Was Produced by People with Bodies, Situated in Time, Space, Culture, and Society, and Struggling for Credibility and Authority, by Steven Shapin, The Johns Hopkins University Press, 2010.  By invitation from Amazon Vine. Uncorrected Proof.

Open Source ESBs in Action, by Tijs Rademakers and Jos Dirksen, Manning Publications, 2009.

Open Source SOA, by Jeff Davis, Manning Publications, 2009.

Rules to Break & Laws to Follow: How Your Business Can Beat the Crisis of Short-Termism (Microsoft Executive Leadership Series), by Don Peppers & Martha Rogers, PhD, John Wiley & Sons, 2008.

Stand Up for Autism: A Boy, a Dog, and a Prescription for Laughter, by Georgina J. Derbyshire, Jessica Kingsley Publishers, 2010. By invitation from Amazon Vine. Uncorrected Proof.

The Service Oriented Enterprise: Enterprise Architecture and Viable Services, by Tom Graves, Tetradian Books, 2009.

Why Can't You Just Give Me the Number?: An Executive's Guide to Using Probabilistic Thinking to Manage Risk and to Make Better Decisions, by Patrick Leach, Probabilistic Publishing, 2006.

New Book Review: "Manage Your Project Portfolio"

Recently posted book review for Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, by Johanna Rothman, The Pragmatic Bookshelf, 2009, reposted here:

Rothman's latest effort is all about how to create and use a project portfolio effectively. Note that while the author discusses how a collection of projects might together form real value, a program, this is not the focus of this book. After discussing project portfolio basics, the author discusses project evaluation, portfolio ranking, portfolio collaboration, portfolio iterations, portfolio decisions, portfolio evolution, and ends by addressing mission. This book was composed very well, and this reviewer especially found valuable the manner in which the author points to prerequisite areas of the book by page throughout in case the reader does not read sequentially. As Rothman indicates, a project portfolio is simply the organization of projects, by date and value, to which the associated organization commits or is planning to commit. A project portfolio helps the practitioner decide when to commit to a project so that a product development team can start or continue a project, understand when it is time to terminate a project so that a team might be freed for other work, determine when to transform a project and commit to the resultant project, and serve as a visual tool to help enable negotiation on how to tackle projects when it is difficult to decide what to do next.

The author points out that "if everyone in your organization (senior managers, middle managers, technical leads, functional managers, and project managers) is wedded to a serial life cycle and no one is willing to consider finishing valuable chunks of work frequently, you can't use a pragmatic approach to managing the project portfolio". In addition, "when your organization's management refuses to make a project portfolio, that lack of decision making is guaranteeing at least one or more schedule games. Or, people will decide which project to work on first, and that decision may not agree with yours. Without project portfolio management, you have more projects competing for the same - and limited - number of people. You find you can't commit to which people work on projects when, you're awash in emergency projects, and you and your staff are running yourselves ragged multitasking" which research has consistently shown to be unproductive. While "Manage Your Project Portfolio" is not a technical text by any means and is expected to be an easy read for most audiences, the author did decide to include a couple of very effective diagrams in the second chapter that if understood by the reader will help navigate the rest of the text by understanding what a project portfolio does for the organization, and what happens when no one manages the project portfolio.

In addition to providing new material, Rothman effectively ties in the insights of a number of other authors in this space, and this reviewer especially enjoyed seeing multiple references to Frederick P. Brooks and Gerald M. Weinberg. The manner in which the author incorporates agile philosophies is especially well done. Her discussion on velocity, both individual and team, for example, is quite effective. "Since I've been working in the field, my managers and clients have been trying to measure productivity. What a waste. Individual productivity means nothing. What does mean something is a team's throughput." While many readers might have already come to the same conclusion, Rothman really drives home this point. "If you try to measure individual productivity, you will get some data. And, the people whom you are measuring will game the data, have no fear. If you measure code, they'll write a ton. If you measure tests, they'll write a bazillion. If you measure files, they will have many more than the project needs. No matter what you measure, if it's not running, tested features, then they will game the system. Don't do it. But you say, I have several single-person projects. Surely I can measure that person's productivity. Um, no, you can't. First, I doubt that those people resist talking to each other. Second, how will you compare productivity? If Davey gets the easy projects and Sally gets the hard ones, who is more productive? I can't tell, and neither can you. Stop trying."