The Importance of the Invisibles (Book Review)

When I read Tom DeMarco’s classic I book Peopleware some time ago, one small part of the book stuck with me. He briefly discusses the idea that some people on teams are Catalysts, people who seem to help a team but who didn’t stand out. As an example, DeMarco describes one person:

“ During her twelve years at the company, the woman in question had never worked on a project that had been anything other than a huge success. It wasn’t obvious what she was adding, but projects always succeeded when she was around.”

This brief acknowledgement of the contribution of someone who wasn’t a star can make to a team stuck with me as something that made sense, but which I never thought about before. David Zweig’s book Invisibles: The Power of Anonymous Work in an Age of Relentless Self-Promotion is an entire book that describes the role of people like this, and thus made a big impression as well. It’s not that some of the people Zweig describes are not incredibly talented and skilled; they are. It’s just that they aren’t the people you think about when you consider what went into a successful concert, perfume, building, or diplomatic discussion.

Invisibles helps you to understand the importance of people you don’t normally think of in our lives, and also explains how their under the radar existence both helps them be effective, but also is enjoyable for them. In addition to learning about what invisibles are and what makes them tick, you also learn a bit about how the traits of invisibles are useful, even if you are someone who enjoys roles in the spotlight.

Invisibles is a surprisingly entertaining and engaging book that not only made its point, but also taught me quite a bit about some professions I knew little about. This book starts with the premise that “invisibles” all share 3 traits, and then introduces you to a few people who illustrate those ideas. I got a review copy of the book because I was intrigued by the premise. As I started the book I thought that it was mis-titled. It seemed less about invisibles themselves, than the jobs they do. But it is through a deeper understanding of the work, and how the people perform their work that you understand what makes invisibles tick. Along the way you also learn a bit about leadership, management, and motivation. At one point, Zweig explains how the desire of some invisibles to help others leads both to very effective groups and projects, and (sometimes) poor individual performance and I was the connection the “Catalyst” role Tom DeMarco describes in Peopleware, and the relevance of this book to people who work in or with teams of any kind, but espectially agile teams.
It’s important to note that not all of the invisibles are all that invisible. One example was a Director of Photography, a role that often is quiet visible on movie credits. But for the most part, you probably didn’t know that many of these people existed, and yet they are essential. (The structural engineer who worked on Falling Water, was responsible for the structure not falling down, in spite of Frank Lloyd Wrights’s design, for example). The book ends by illustrating how we often notice these invisible roles only when the persons performing them fail, or when we don’t engage them to do their jobs.

Having read this book, I’m realizing that I sometimes took the importance of invisibles for granted. Sometimes inwardly focused star performers are more effective when being helped by someone who can help keep the team focused on the goal. This isn’t the message that we are often told. The usual message is that it’s a star performer who saves the day. One recent exception is the Lego Movie (which I won’t claim to be anything more than a fun, self-aware film, but I have seem it a few times with my 7 year old). It is reassuring to see real stories of the value of people who are not in the spotlight.

In software development much of the useful work happens among teams of skilled professionals, all of whom need the work of the others to produce really great products. As an advocate for agile practices, and a Scrum Master, I realized that the importance of individual enablers. While I get to facilitate meetings and play some central roles, I also know that at the core, a good Scrum Master is a servant leaders, for whom the best praise is praise directed at the team.
Invisibles doesn’t torment you with its message that there are 3 traits that invisibles have. It tells stories and examples to makes its point, and even if you don’t fully buy it’s message, you end up having learned some things you didn't know and with some things to think about.
I was surprised at how much I enjoyed this book, and how much it helped me to learn and made me think. If you like books about work style, motivation, or are just a curious person, this book is worth a look.

Books and other media I mentioned above

Gulp! (Book Review)

It could be that I'm the parent of a 7 1/2 year old boy. It could also be that the book has such great footnotes ( when I was in grad school working on a paper for a group project, one of my fellow students commented that I wrote great footnotes), but I found Mary Roach's book Gulp: Adventures on the Alimentary Canal to be very engaging and entertaining, as well as educational.

Gulp is a very approachable "top-to-bottom" tour through the human digestive system. Combining fact, history, some editorial commentary, and much humor you can't help but get pulled into this book, and even pull in those around you. At various points I found myself laughing out loud, leading my wife to comment that I,  have a lot more in common with our 7 year old, or at least that there is a certain timelessness to that sort of humor among certain demographics. The chapter on flatulence was particularly amusing, and was a great example of how Roach uses humor to help us learn about socially awkward topics, and to make details memorable.

One of the charms of this, and the other books of her's that I have read, is that she is adept at staying on the correct side of the boundary between humor that makes us comfortable (and makes facts memorable), and humor that is just awkward. She did a similarly good job with Stiff: The Curious Lives of Human Cadavers.

While this isn't the book to read for serious research, it is a good place to learn some fun facts about a subject that is not often discussed in polite company. With footnotes and references, you also have a good starting point in case you want to learn more. The only down side of reading the book is that you may find yourself laughing out loud or at least finding it hard to share a particularly amusing storing with whoever is sitting next to you while you are reading.

Gulp is a great example of how you can be entertained, informed and educated at the same time.

Gulp: Adventures on the Alimentary Canal

 

Book Review of Java Performance: The Definitive Guide

While tools and technologies change rapidly, and looking up information online is sometimes the best way to get the information you need, I can be useful to occasionally read a book to get oriented in a subject and discover what you didn't know that you didn't know. For me a good technical book sets the context for the problem and gives you enough information to apply what you learned to harder problems that the book covers, but which also gives you information you can apply immediately.  Java Performance: The Definitive Guide does a good job of both.

Not just about JVM params, the book covers application and algorithm issues, database connectivity, as well as JVM issues such as garbage collection algorithms. What is useful, and sadly rare,  is  that this book not only tells you things you can do,  it also tells you things that you can skip, since not every thing you do has a good cost/ benefit payoff.

With an emphasis  on standard tools, including open source and those that come with the JDK,  you can apply what you learned immediately. The book does not cover every tool, and may not include your favorite, but the discussion has enough  tools to get you started.

This book will be useful for both those new to programming in Java (since performance and resource use area rarely emphasized who you are learning to program) and those who have been programming a while but have not spent as much time thinking about performance as one might like.

I got my copy of this book through the Amazon Vine program.

Estimation as a requirements Exercise

I explored the role of estimation in a couple of articles on Techwell recently.

In the first article I discussed how teams balance the cost of estimation (in terms of time it takes) with the value it brings to the project. Some argue that estimation isn't very useful at all, where other's say that it can be useful, but that all stakeholders may not have the same vision of the value estimation brings.

In a follow up article I explore the debate about whether to estimate in hours, which reflects effort, and time, or  points, which reflect complexity. This is a common debate, since many articles on agile advocate points, to step away from the concepts of estimate, and focus on the complexity of a feature, and also to help teams move towards the model of the estimate being valid for the team and not just a particular person. And stakeholders are often concerned about schedule and deadlines, so tend to prefer hours initially.

Different teams will come to different decisions about what works best for them. To me the most important part of the estimation discussion is the part many teams don't have, namely asking (and answering) the question of why they are estimating, and what value the estimates bring to the project given that they are now working with an agile process.

As I think more about what value estimation has brought to teams that I have worked on, I realize that the biggest value is that of having a a discussion of scope. When you have an planning meeting, a few questions come up:

• Why people have different estimates
• Why the estimate is larger, or smaller, than the product owner expected
• Whether the team really understands what the story means.

Give this I'm leaning towards thinking of estimation as being more about requirements definition rather velocity, effort, or even complexity.  To that end, maybe the approach to use is one where you spend all of your planning effort defining stories in terms of small, fixed size units, and your velocity is about how many stories you finish off of a prioritized backlog. I link to a description of what this means in the points and hours article.

I'm  interested in hearing about creative approaches your teams have used for estimation. Please comment on  the Techwell articles, or here if you want to share lessons you have learned.

Pattern-Oriented Software Architecture For Dummies (Book Review)

When I received a review copy of Pattern-Oriented Software Architecture For Dummies, by Bob Hanmer, one of the leaders in the Patterns community, I was intrigued. Patterns are more complicated to understand than they appear, and I wondered how a book like this could do justice to the topic. I was not disappointed.

This book is one of the few books that is a good tour through the fullness of the patterns universe. It's an easier read than many other books on Patterns, and it covers the basic concepts of what a pattern is, and gives examples of how to use patterns correctly.
The book focuses on the Patterns from the Pattern Oriented Software Architecture series and the classic Design Patterns: Elements of Reusable Object-Oriented Software book. The book wraps up with a tour through the larger pattern world, with examples from patterns in areas such as configuration management, software process, and user interaction.

Patterns are one of the most misunderstood concepts in software. Patterns are more than just what the English language definition of the word implies, and by their nature, Patterns are not novel ideas; you’ve seen them before because they work. Because of the superficial simplicity of Patterns, using software patterns effectively can be tricky. Patterns are more than just the structure of the software. Patterns also involve the context in you apply them, and the problem that you are trying to solve. Newcomers to the concept of patterns also sometimes mistake the number of patterns in a solution with a good solution. This book does a good job of addressing these essential aspect of working with and understanding patterns.

A better title of the book might have been “Using and Understanding Patterns (for Dummies)” since I feel that most readers will walk away from the book with a better understudying of what patterns are, than about how to build architectures, but it’s a good starting point never the less. The first section of the book spends a bit more time than needed on tools and approaches for describing architecture, but the rest of the book is worth a read if you feel that you don’t understand what patterns are.

There are few books that cover that such a broad sweep of the patterns landscape so concisely. When you’re done you’ll want to read more, guided by the resource section at the end of the book. This is a good resource for a software developer who wants to learn more about patterns. Those familiar with patterns, but not patterns beyond the building block Design Patterns will find this book a good reminder that there is more to the patterns universe. This is not as thorough as a guide to architecture patterns as books like Pattern-Oriented Software Architecture Volume 1: A System of Patterns are. And it's not meant to be. But if you are looking to understand why you might care about patterns that describe working at a system level, and have not found a good resource to do this yet, this book is worth a read.