Agile Reading
The first post-resolution book I've cracked so far is Craig Larman's Agile and Iterative Development. The plan I've formulated, based on said resolution, calls for me to get through at 2+ books on agile methods in the next 2 months, in addition to the platform-sepcific reading I need to do. My reasoning is that although I may be playing catch-up on specific technologies, I can get at least slightly ahead in the area of methodology and project planning. Not that I think I'll be the only developer in Atlanta that knows about agile methods, but my experience tells me that, for whatever reason, it's not something that most of my peers are really diving into.
As further background for my decision to make a focal point of Agile methods, I should point out that virtually every single experience I've had in my career thus far has led me to the conclusion that, for the vast majority of business software, some flavor of iterative development methodology is the way to go. Any time I get involved in a position where someone is clamoring for a heavyweight up-front requirements period, or for extensive documentation, or where people immediately start in with "it's not time to talk about code yet," my spider-sense goes off like an H-Bomb. I'll almost certainly return to this point again and again, as I think it's something I've already discussed in the few posts I've made previously.
Anyway, I should note that this book is part of the Addison-Wesley Agile methods series, edited by Hightower and Cockburn--a series which I've heard great things about edited by two professionals whom I respect a good deal. I'm about halfway through already as it's a very quick and easy read, just a summary of the title topic from the 10,000-ft view aimed at newbies and managers. I'm not really either of those things, but when I looked through the book I saw it as a great source of ammunition and ideal info to have on tap for non-believing managers and curmudgeony types with their methodology still stuck at "GOTO considered harmful."
Thus far it's proved a good purchase decision. Larman's a very readable author, and this book does an admirable job of summarizing why waterfall, in general, sucks. Although there's a high possibility that it won't remain on my shelf due to it's generality, it will almost certainly remain on my recommendations list--especially for managers.
What? Me review?
Certainly -- I'd like to write some more reviews.
I went through some gyrations about how worthwhile this one would be, but its value has become apparent as I've continued reading. Like I indicated, I bet I'll end up loaning this one out or just straight giving it to a manager type sometime. That's the intended audience, and it's aim is dead-on.
I'll have to check that article out. Thanks for the heads-up
-A


Craig Larman
I have not yet read the Craig Larman agile methods book you mention, but I liked reading his UML/patterns book, the first edition of which he wrote (if I'm not mistaken) before later becoming interested in agile methods (it's now in a third edition, and still a bestseller). Another piece of writing from Larman that I've liked is this article about "protected variation" as an alternate term for David Parnas's groundbreaking concept of "information hiding." (PDF)
Hopefully soon I'll have the new developerdotstar.com Books area up and running and maybe you can post a review when you're done with the book.
Dan