Scan barcode
henrik_w's review
3.0
Adrenaline Junkies and Template Zombies is a collection of 86 patterns of project behaviour collected and documented by a group of 6 authors from the Atlantic Systems Guild.
Each pattern is presented with a title, a picture, a one- or two-sentence summary, and a few pages describing the pattern in more depth. This format works pretty well, and the book is both funny and very easy to read. However, when I finished reading the book and asked myself what I had learnt from it, I had to answer "Not much".
That's not to say it's a bad book, just that if you have been working in software development projects for a few years, there aren't that many new insights here. However, the book does a good job of singling out and labelling various project behaviours (usually bad ones), which is useful.
Of all the patterns in the book, the ones I liked the best were "The Blue Zone", "Practicing Endgame", "Mañana" and "Time Removes Cards from your Hand".
"The Blue Zone" describes the green zone, which is anything that is explicitly ordered or allowed by the project, and the red zone, which is anything explicitly forbidden. The blue zone is everything else, activities that are neither explicitly allowed, nor explicitly forbidden by the scope of the assignment. In the authors' opinion (and in mine, too), it is good to sometimes operate in the blue zone, in addition to in the green zone, in order to achieve the best outcome. Or, in the words of the quote ending the pattern: "The correct amount of anarchy on a project is not zero".
In "Practicing Endgame", the idea is that you should be thinking about and testing against your release criteria continuously, as opposed to leaving that till the end. The analogy given in this pattern is that of the university course, where you may have several tests throughout the term, in addition to the final exam. This "continuous" exam preparation gives better results than the one-off method of only having the final exam.
The last two of the patterns I liked the most both deal with time.
"Mañana" simply states that if your goal date is more than 30 to 90 days out, you need to set sub-goals that are within 30 to 90 days, in order to make the people on the project feel the right sense of urgency.
"Time Removes Cards from your Hand" describes how you have fewer and fewer options the longer you pretend that everything is fine, even though things are not fine. You might end up with many half-finished features, instead of a few completely finished features, and it might not be the most urgently needed features.
Except for the concept of the blue zone, which I like and which I had never seen explicitly described before, even the patterns I liked are not really teaching me a lot that I didn't already know.
In fact, if you are using agile methods like XP or Scrum, then you will recognize a lot of the patterns and advice as standard agile working procedures ("Straw Man" is another example of this).
On the other hand, there are a number of examples of anti-patterns from (it seems) process-heavy larger companies, for example "False Quality Gates" (documents are check for format, not contents), "Paper Mill" and "Orphaned Deliverables" (both deal with places where the measure of progress is documents, not working software), and "Cider House Rules" (rules are made by people unconnected to the project).
When it comes to the names given to the different patterns, there are some hits and some misses. A name that is both catchy and describes the pattern in a good way makes the pattern so much easier to remember. My favourite is "Template Zombies", which I think is pretty self-explanatory, but "One Throat to Choke" is also very good. But naming is hard, and there are many patterns that I feel have pretty awkward or non-descript names, like "Lease your soul" (about how to adopt new technology - I'm thinking more in terms of a tool-box than selling/leasing your soul to some new technology) and "System Development Lemming Cycle" (that the process used isn't tailored - but where did the lemmings come from?).
Another complaint is that the different patterns presented in the book are not organized around themes - instead they are just put in random order. I would have preferred if they were grouped together, since many of the patterns deal with related concepts.
So, in summary, the patterns in the book cover many different project behaviours. The descriptions are useful and well written, but if you have been involved in software development projects for a while, most of the patterns should already be familiar to you. Still, they may serve as a useful reminder - plus, you get (in many cases) snappy names for some of the behaviours, which may make them easier to diagnose and talk about.
Also, if you're interested in this book, check out episode 131 at Software Engineering Radio. That podcast is an interview with Tom DeMarco and Peter Hruschka about this book, and it is well worth listening to.
Each pattern is presented with a title, a picture, a one- or two-sentence summary, and a few pages describing the pattern in more depth. This format works pretty well, and the book is both funny and very easy to read. However, when I finished reading the book and asked myself what I had learnt from it, I had to answer "Not much".
That's not to say it's a bad book, just that if you have been working in software development projects for a few years, there aren't that many new insights here. However, the book does a good job of singling out and labelling various project behaviours (usually bad ones), which is useful.
Of all the patterns in the book, the ones I liked the best were "The Blue Zone", "Practicing Endgame", "Mañana" and "Time Removes Cards from your Hand".
"The Blue Zone" describes the green zone, which is anything that is explicitly ordered or allowed by the project, and the red zone, which is anything explicitly forbidden. The blue zone is everything else, activities that are neither explicitly allowed, nor explicitly forbidden by the scope of the assignment. In the authors' opinion (and in mine, too), it is good to sometimes operate in the blue zone, in addition to in the green zone, in order to achieve the best outcome. Or, in the words of the quote ending the pattern: "The correct amount of anarchy on a project is not zero".
In "Practicing Endgame", the idea is that you should be thinking about and testing against your release criteria continuously, as opposed to leaving that till the end. The analogy given in this pattern is that of the university course, where you may have several tests throughout the term, in addition to the final exam. This "continuous" exam preparation gives better results than the one-off method of only having the final exam.
The last two of the patterns I liked the most both deal with time.
"Mañana" simply states that if your goal date is more than 30 to 90 days out, you need to set sub-goals that are within 30 to 90 days, in order to make the people on the project feel the right sense of urgency.
"Time Removes Cards from your Hand" describes how you have fewer and fewer options the longer you pretend that everything is fine, even though things are not fine. You might end up with many half-finished features, instead of a few completely finished features, and it might not be the most urgently needed features.
Except for the concept of the blue zone, which I like and which I had never seen explicitly described before, even the patterns I liked are not really teaching me a lot that I didn't already know.
In fact, if you are using agile methods like XP or Scrum, then you will recognize a lot of the patterns and advice as standard agile working procedures ("Straw Man" is another example of this).
On the other hand, there are a number of examples of anti-patterns from (it seems) process-heavy larger companies, for example "False Quality Gates" (documents are check for format, not contents), "Paper Mill" and "Orphaned Deliverables" (both deal with places where the measure of progress is documents, not working software), and "Cider House Rules" (rules are made by people unconnected to the project).
When it comes to the names given to the different patterns, there are some hits and some misses. A name that is both catchy and describes the pattern in a good way makes the pattern so much easier to remember. My favourite is "Template Zombies", which I think is pretty self-explanatory, but "One Throat to Choke" is also very good. But naming is hard, and there are many patterns that I feel have pretty awkward or non-descript names, like "Lease your soul" (about how to adopt new technology - I'm thinking more in terms of a tool-box than selling/leasing your soul to some new technology) and "System Development Lemming Cycle" (that the process used isn't tailored - but where did the lemmings come from?).
Another complaint is that the different patterns presented in the book are not organized around themes - instead they are just put in random order. I would have preferred if they were grouped together, since many of the patterns deal with related concepts.
So, in summary, the patterns in the book cover many different project behaviours. The descriptions are useful and well written, but if you have been involved in software development projects for a while, most of the patterns should already be familiar to you. Still, they may serve as a useful reminder - plus, you get (in many cases) snappy names for some of the behaviours, which may make them easier to diagnose and talk about.
Also, if you're interested in this book, check out episode 131 at Software Engineering Radio. That podcast is an interview with Tom DeMarco and Peter Hruschka about this book, and it is well worth listening to.
wolvereader's review
3.0
As far as patterns books go, this one was pretty light on the "pattern" part. It was more a series of short essays about things observed on project teams. Some of them offered advice. Some of them were more anti-patterns--things to avoid. Some were just strange. (The "IT seems to have a higher proportion of musicians" was a particularly useless 'pattern'.)
There are a few gems in here, especially around distributed development and high performing teams. There was lots that will be familiar to Agile practitioners, and there was lots that you'll recognize as happening in your own organization, both good and ill.
Overall, this is an easy read with some value, but if you're trying to learn about project management, you'd be better off starting with more focused books. On the other hand, if you're currently running a team or three, it couldn't hurt to leaf through here to remind yourself what you're doing right--and what you need to fix.
There are a few gems in here, especially around distributed development and high performing teams. There was lots that will be familiar to Agile practitioners, and there was lots that you'll recognize as happening in your own organization, both good and ill.
Overall, this is an easy read with some value, but if you're trying to learn about project management, you'd be better off starting with more focused books. On the other hand, if you're currently running a team or three, it couldn't hurt to leaf through here to remind yourself what you're doing right--and what you need to fix.
will_sargent's review
3.0
It's all right.
The problem that this book has is that it's a list of patterns. Each of these patterns stands on its own, but does not feed into an overarching theme. As such, I got the feeling of "yes, I've seen this before" but nothing that told me "ah, this is why this happens." Simply listing things isn't going to lead to any epiphanies, but it's nice to see that some behaviors seem to be universal.
The problem that this book has is that it's a list of patterns. Each of these patterns stands on its own, but does not feed into an overarching theme. As such, I got the feeling of "yes, I've seen this before" but nothing that told me "ah, this is why this happens." Simply listing things isn't going to lead to any epiphanies, but it's nice to see that some behaviors seem to be universal.
More...