My very talented friend Clarke Ching has self-published his second novel Rocks into Gold (his first, Rolling Rocks Downhill, is due out later this year).
Rocks into Gold is a “parable for software developers who want to survive — and then thrive — through the Credit Crunch”. If you’re a subscriber to this blog you’ll probably know the book’s main message already; but read it anyway, because you probably also know someone who’s project, or job, or organisation, might just benefit from Clarke’s excellent re-telling — buy them a copy.
Way back in 1999 Martin Fowler published Refactoring — Improving the Design of Existing Code. Fowler’s book introduced the world to refactoring as an independent practice, and provides dozens of detailed mechanical recipes, each of which describes the steps needed to change one (usually small) aspect of a program’s design without breaking anything or changing any behavior.
To be skilled in refactoring is to be skilled not only in safely and gradually changing code’s design, but also in first recognizing where code needs improvement — recognition of code smells. This is where William Wake’s brilliant Refactoring Workbook (2003) comes in. Bill’s book focuses on Java code smells: Each chapter consists of descriptions of a few major code smells, followed by a number of exercises to work through (the challenges vary; some ask you to analyze code, others to assess a situation, still others to revise code).
But what if you’re not a Java developer? Good news: Early next year Jay Fields, Shane Harvie and Martin Fowler are publishing Refactoring, Ruby Edition. It’s available now as a Safari Rough Cut.
And as if that weren’t enough good news, Bill Wake and I are writing the Ruby Refactoring Workbook. Compared with Bill’s original Java Refactoring Workbook our Ruby edition will have a similar overall structure, but is otherwise a substantial re-write. We have retained the core code smells (and added a few more) and re-worked them to apply to Ruby’s more dynamic environment. We have replaced all of the code samples, and replaced or revised all of the exercises. We have also re-written much of the introductory material, mostly to reflect the rise in importance of test-driven development during the last five years. In short, we’re trying to create a stand-alone Ruby refactoring workbook for the modern developer, and not simply a Java book with Ruby code samples.
As things stand right now we have three chapters left to write, and a deadline to get the first draft to our publisher next month. I hope to start releasing draft text into the wild for comment fairly soon, so watch this space if you’d like to be involved!
This week’s April meeting of the AgileNorth group was a book review. Kevin Dockerill reviewed Mary Poppendieck’s Lean Software Development and Ken Schwaber’s Agile Software Development with Scrum. We spent about forty-five minutes discussing each book, and then half and hour or so comparing the two methods, particularly in relation to applying them in Kevin’s own small team.
While reading the books in preparation for the meeting, Kevin had created a little summary leaflet for each. Each leaflet was in two parts: the first stepped through the book’s chapters picking out the main points, while the second provided Kevin’s commentary and opinion. (In the case of the Scrum book, Kevin also rated each chapter out of 10 – from which we discovered that the first half was much more to his taste than the second!) The format of Kevin’s little leaflets worked extremely well, and I would recommend this kind of approach for any subsequent book review. I particularly liked the idea of chapter ratings, which gave us an at-a-glance view of Kevin’s opinion and also highlighted the two very different halves of the Scrum book.
As the meeting progressed, the discussion moved away from the books and on to comparing and contrasting the two methods – Scrum vs. lean. I was too engaged for taking notes, but I recall some main themes emerging in the opinion of the group as a whole:
Scrum is likely to serve well in a traditional, structured, command-and-control organisation, where strong project management and reporting lines reign. Whereas the Lean book offers a bag of tools, and so will probably appeal to more ‘fluid’ organisations.
The mapping of software development to manufacturing is not helpful to organisations that aren’t used to growing their own processes and adapting them regularly.
The Lean book maps specific practices from lean manufacturing into software development, without providing enough background on why those practices are appropriate.
It seems unlikely that many software projects could go 30 days without changing their requirements; so Scrum seems to be targeted at bigger projects.
This was an enjoyable evening, made very productive by Kevin’s thorough and thoughful preparation. I’m looking forward to the next one, on May 15th!
What were your first impressions when you read these two books?
“The best source on ‘lean’ (in the broad sense) for product / software development is Reinertsen’s Managing the Design Factory. It’s fantastic. Lot of Mary and Tom’s stuff is from it.” — Clarke Ching
“Thinking Beyond Lean is about the product development model of car manufacturers and how Toyota completely overhauled their product development process, at a time when some of their competitors were starting to copy Toyota’s process. See here for a first stab at mapping the ideas in the book to agile software development.” — Pascal van Cauwenberghe
“I’d been thinking that I should read more about lean manufacturing; what are your favorite books on the topic? And am I correct in assuming that the Poppendieck book is where to start for lean software development?”
Lean manufacturing is indeed a fascinating topic, particularly in the week that Ford in the US seems to have completely failed to understand it…
I guess I began by going to the horse’s mouth to read Taichi Ohno’s Toyota Production System. After that there’s a wealth of material out there. Many of the most approachable are those written by Westerners for Westerners: such as The Machine that Changed the World or Lean Thinking by Womack & Jones, or Liker’s The Toyota Way. Others are more specialised, such as Imai’s Gemba Kaizen.
Lean manufacturing concepts – such as pull, jidoka, gemba etc – can be applied to software development with positive effect (see Lean Software Development by the Poppendiecks). However, beware of drawing parallels between software development and manufacturing. In a software production business, the “manufacturing” step is largely about packaging and burning CDs etc, whereas software development itself is what folks in hard engineering call “Product Development” or “Engineering”. Toyota’s approach to product development is often termed Knowledge Management or the Learning Organisation, and their performance there is perhaps even more startling than it is in manufacturing. Yet there’s little approachable material available. I began with Kennedy’s Product Development for the Lean Enterprise.
There is a growing body of information available about knowledge management and learning organisations – I’m currently working my way through Takeuchi & Nonaka’s Hitotsubashi on Knowledge Management. However, with the exception of influences in the Poppendiecks’ book I know of very little material mapping these concepts directly onto software development.
(Inevitably my reading has been patchy and is woefully incomplete. So please let me know if you’ve read books I’ve missed here – particularly any that deal more explicitly with mapping software development to knowledge management and learning organisations.)
In comp.software.extreme-programming yesterday Laurent Bossavit produced out of the hat the following quote from Donald Finkel’s book Teaching with your Mouth Shut:
“No thought, no idea, can possibly be conveyed as an idea from one person to another. When it is told, it is, to the one to whom it is told, another given fact, not an idea. The communication may stimulate the other person to realize the question for himself and to think out a like idea, or it may smother his intellectual interest and suppress his dawning effort at thought. But what he directly gets cannot be an idea. Only by wrestling with the conditions of the problem at first hand, seeking and finding his own way out, does he think.”
This is Laurent’s support for the idea of learning the craft of programming via kata, and for me it hits the nail right on the head. Finkel’s method seems also to be supported by NLP (neuro-linguistic programming) philosophy, in which the meaning of what one person says is defined as the impact it has on the listener…
For years now I’ve been looking for that one book that would provide good background reading material to help teach object-oriented software development. Currently I’m reading Extreme Programming Adventures in C# by Ron Jeffries, and I think this book comes closest to fitting my needs. I’m sure not everyone will appreciate the very informal style, in which Ron takes us along for the ride while he develops a new application and learns a new language. But I find the lessons he learns along the way – and the development process he promotes – fascinating. I have yet to find a better introduction to object-oriented design and development.
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.