I will be submitting a book review for the Bunkhouse (still waiting for my copy though). I'm limited to 200 words for the review so I'm just going to post my notes here as I go through the draft that I downloaded from Alistair's website. Feel free to chime in with your own thoughts. Junilu
Is software devlopment an art, a craft, science, engineering, or something else entirely? Does it matter? Yes, it does matter, and it matters to you. Your actions and their results will differ depending on which of those is more correct.
Answer: "something else". The author writes that software development is a game. But how does it really matter? It matters because the way you see something affects your attitudes towards it. Take gardening for instance. If you see it as a chore (or something that you have to do because your spouse won't do it :roll: ), your attitude/inclination/motivation for doing it will be different than if you see it as a hobby. In the same way, seeing software development as a game puts it a totally different perspective than if you see it as an engineering effort and your attitudes and approach will be different. [ March 01, 2002: Message edited by: Junilu Lacar ]
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck
Another stated objective of the book is to establish a vocabulary to use as a way of reflecting on experiences and learning from them. The vocabulary helps us notice things that we would otherwise have no way of putting a finger on. This seems closely related to seeing S/D as a game. Terms like "winning" and "moves" come about from this viewpoint. "Phases" doesn't seem like a word that would naturally be a part of the game vocabulary although "stages" or "period" might be (as in "at this stage of the game"). Reflecting on this concept reminds me of rice. My native language has many words for rice in much the same way that Eskimos are supposed to have many words for snow. The concept of vocabulary affecting how we see things and vice versa does seem to be valid.
The first part of this book will probably make you step back and reflect on quite a few things. The first thing it made me do was to look back at my own learning experiences. Alistair talks about 3 stages of behavior or practice: following, detaching, and fluent. Alistair also mentions shu-ha-ri, which roughly means learn, detach, and transcend and draws parallels in their application in Aikido and software development. Very interesting reading. The book is aimed more at level 2 and 3 readers, those who are testing the limits of what they have already learned and are trying out alternatives, taking the next step in learning (detaching) and those who don't really care about what technique they use and just naturally know and do what's needed to accomplish the job (fluent). Try looking back and remember things that you found to be difficult to learn. Did you have good models to follow? How did this affect your learning? Junilu