Software For Your Head

CategoryBook: Software for Your Head: Core Protocols for Creating and Maintaining Shared Vision by Jim and Michele and McCarthy, ISBN 0201604566 .

This book describes the lessons of the McCarthy software development bootcamp.

Book review on http://www.xprogramming.com by Ron Jeffries.

http://www.xprogramming.com/xpmag/books20020208.htm

: "If you are serious about your profession, if you are serious about teamwork, if you are serious about success, please read this book."

See TheCore.

One cool thing about this "software" is that it is under the GNU public license. (See the appendix.) Moreover you can download it from http://www.mccarthy-tech.com/logon/index_core.asp

One uncool thing is that it talks about software developers setting personal goals, without giving any concrete examples. What could it mean?

Yet another MindFsck, this one keying on the insecurity engineers feel toward their teams. If you'd like to behave robotically and give up responsibility for determining your own basis for action, just follow the bouncing ball ...

Which page does it say you should behave robotically?

I'd like to know, also, what page says you should behave robotically. As for MindFsck, the book recommends figuring out what you want, in a sense. It's called the "PersonalAlignment?" protocol. It's hard to figure out. Or, it's really easy to get wrong. The author gives an example list of good alignments, and an example list of bad alignments, and then a list of criteria as to why the bad ones are bad, but a closer inspection only led me to confusion because some of the good ones were not clearly free of the faults in the criteria. So I am somewhat at a loss on the topic of Alignment. It might be a bullsh1t generator. It's hard to tell. If you insist that someone give you an Alignment, they'll eventually tell you what you want to hear, just so you'll get off their back.

It is too easy to criticize this book, because there are so many flaws. However, there are so many good things to take from this book, I recommend it highly! For example, this would clearly be a better world if more people were aware of the ResolutionAvoidance? antipattern. I count 24 patterns in the book, 14 antipatterns, and 15 protocols. Most of them are good. Some are not so obviously good.

More flaws: The author has the annoying (to software developers) habit of frequently using words before defining them, and a tendency to redefine words, sometimes in useless ways. At one point, the author redefines "intent" to include results, and thus you always get the results that you "intend". At another point he redefines "developer" to include everyone on the team, including the manager, thus creating a synonym for "team member" and depriving us of what seems to be a useful distinction (which may have been the intent, who knows?). Such little patches of pointy hair pop up every so often in this book.

And the end of the book seemed rushed. I didn't quite get my mind around the Feedback antipattern. It is hard to fathom how Feedback can be an antipattern! It is probably just the choice of name, but even so, the rest of the description I did not find enlightening. It ends finally with the PerfectionGame?, which seems to be just tacked on. Who knows, it might be a fun and useful protocol, but I haven't tried it, and it's weird. The book ends abruptly there: no summary, no conclusion. Just appendices.

Many of the things you say strike me as true. See my review on BookShelved: http://bookshelved.org/cgi-bin/wiki.pl?SoftwareForYourHead. (You're welcome to contribute your own opinions there...)

All feedback isn't bad, just unsolicited feedback. (Unsolicited) Feedback is an anti-pattern because it turns communication from a two-way activity into a broadcast activity. "You have to listen to me, because I'm giving you feedback." It suggests that the person giving the feedback has insights that the listener doesn't have. This assumption doesn't always ring true - since feedback really is just advice, we all know there's plenty of "bad advice" out there. Feedback as a communication structure is imperfect because it encourages lax thinking on the part of the giver - it's frowned upon for the listener to challenge feedback, for the simple sake that it's feedback, and MUST be something useful for the listener.

Furthermore, Feedback assumes that "if you say it, they will come" - i.e. if I give you a performance review highlighting room for improvement, you will improve. This isn't new - WilliamEdwardsDeming also suggests abolishing all performance reviews.

Unsolicited feedback ignores that the only way someone will listen to anything is if they're receptive to such advice. And the only way to be sure someone is receptive is that they ask for your assistance. And under such circumstances, it's no longer feedback, it's discourse, and has the potential to be dialogue.

Throughout the book, the general impression I got was that offering your advice was the limit of feedback one should give. People have to ask, and be receptive, for it to be effective. -- StuCharlton