Sometimes memes strike me as simply childish. But here’s one (via The Vision Thing) that may reveal just a little about the people taking part. The meme is this:
Grab the nearest book.
Open the book to page 123.
Find the fifth sentence.
Post the text of the sentence in your journal along with these instructions.
Don’t search around and look for the “coolest” book you can find. Do what’s actually next to you.
I read that blog post while sitting on one of the sofas in our conservatory, which we’ve reserved as a child-free adults’ reading room. On the cushion next to me was the book I’m currently reading – Getting Things Done by David Allen. Spookily, the book was already open at page 123, which is precisely where I had read upto yesterday. Counting the sidebar, the fifth sentence reads thus:
“The in-basket is a processing station, not a storage bin.”
This is really one of the central messages of the GTD school of self-management. By removing the pressure created by having a full in-tray, Allen claims we can release our creative energy and thereby accomplish much more. I’m very optimistic that this system will work for me, and I’ll be implementing it during the upcoming Easter break. I’ll let you know how I get on…
I recently finished reading Lean Software Development by the Poppendiecks. This book has a lot to offer in terms of practical tools to help software coaches and teams “go lean.” But I was left with an uneasy feeling at the end, which I think may be attributable to two (related) causes.
First, the approach and tools are presented as if they somehow represent “the” mapping from lean manufacturing into the software world. But surely the seven principles and twenty-two tools are only one way to perform leaner software development. And while the authors never suggest that these are in any way canonical, one is left with an impression that absolutely everyone should start from this tool-kit, and that to not do so would be to fly in the face of Toyota wisdom.
Second, the metaphor used by the Poppendiecks to relate software development to manufacturing is not explored. Can software development really be treated as an analogue to manufacturing? I believe that there is some combination of the “classic” set of manufacturing business processes that can be mapped onto software development. But that mapping is non-trivial, and when complete will not necessarily yield the picture painted by this book.
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!