Based on Clarke’s recommendation I’ve just finished reading Crucial Conversations. And I have to agree – this is a terrific book. It contains three or four critical ideas that help to make those difficult, emotional conversations a lot more easy to understand – and hopefully then to master…
I must admit, though, to being somewhat irritated by the cutesy names the authors use for the various techniques – ABC, CRIB, STATE my path etc. Useful and important as they are, I won’t remember them in that form, so I’ll need to find another set of names for them.
While reading, I found myself comparing it to the equally excellent Getting to Yes by Fisher, Ury and Patton. Some of the same ground is covered in both books (getting away from emotions and back to basics), and I would certainly recommend reading both together. So now, when faced with an important discussion, should I treat it as a crucial conversation or as a negotiation? Or both?
On Clarke‘s recommendation I just finished reading Critical Chain by Eli Goldratt. This is another of his “novels”, in which this time he applies the ideas of TOC to project management. I liked the book’s use of the TOC thinking tools. And I also liked the discussion in the last couple of pages, about using dollar-days as the unit to measure investment – although I need to think about it a lot more before I’ll come close to understanding it.
The main thrusts of the book are that managing slack at the project level is better than managing it per task, and that the critical path/chain is the bottleneck in a project, and therefore needs to be protected. Again, I need to think about this a lot before I can fully see how – or whether – these ideas will apply to an agile software project…
I really must get around to reading Object Thinking. It gets a reasonable review from Darrell Norton among others, and Andy even uses it to support my own metrics!
When it comes to coaching teams in object-oriented design, I’ve always had trouble finding good reading material to give out. Books I’ve tried include:
Bertrand Meyer’s Object-Oriented Software Construction. Back in the early nineties this was just about all that was available. While it does emphasise the behavioural view of objects, the use of Eiffel doesn’t help, and there’s little help with concepts such as refactoring or the need to eliminate duplication.
Rebecca Wirfs-Brock’s Designing Object-Oriented Software. I’ve always liked this book, but for some reason British Java programmers never seem comfortable with it. And again, it has little to say about code structure or quality.
Kent Beck’s Smalltalk Best Practice Patterns. This is my favourite of the three, because the patterns directly apply to refactoring code into great designs. But again, I’ve found that Java programmers seem scared to death of reading smalltalk.
Is Object Thinking what I’ve been looking for? Or is there another book out there that can show talented programmers what great code looks like?
Update, 9 may 05
At last, I’ve found a very good candidate!