It turns out I co-wrote the feature article in this month's Better Software magazine!

I just posted this review of Wabi-Sabi: For Artists, Designers, Poets and Philosophers by Leonard Koren:

This is a wonderful little book about the Japanese art style called Wabi-sabi. The book is short, and many of the pages consist solely of full-page photographs illustrating the ideas. So it's a quick read, but worth taking the time to read slowly, let it sink in, and then read again.

Wabi sabi itself originated as an eclectic style of the Japanese tea ceremony, emphasising the impermanence and ever-changing quality of all things. But the book keeps its feet on the ground and doesn't spend too much time deep in Zen territory.

I read this book on Kent Beck's recommendation during the early years of eXtreme Programming -- see http://c2.com/cgi/wiki?WabiSabi for more on that. As an XP/agile coach I recommend it to any team that gets hung up on the search for perfection, to remind them that every state is transitional, and the idea of anything being "finished" is an illusion.

While browsing around other folks' blogs today I came across a link to a post I wrote back in March 2005. Six years on I think it still stands up, and so I commend it to you, dear reader: The Middle Hexagon Should be Independent of the Adapters.

"I smile and start to count on my fingers: One, people are good. Two, every conflict can be removed. Three, every situation, no matter how complex it initially looks, is exceedingly simple. Four, every situation can be substantially improved; even the sky is not the limit. Five, every person can reach a full life. Six, there is always a win-win solution. Shall I continue to count?"

-- Dr. Eliyahu M. Goldratt, 1947- 2011

Eli Goldratt wrote many books, and among them these four stand out as having changed my work (and life, I guess) for the better:

• The Goal -- a novel, about a chap who has three months to save a failing factory. This is where it all began, and the ideas apply to so many different situations in so many different fields. I'd include this in my top 5 books of all time.
• It's Not Luck -- another novel, and the sequel to The Goal. Provides a basic introduction to the Thinking Tools by showing how to use them in analysing a variety of business problems.
• The Choice -- a manifesto, quoted above. In this book Goldratt takes to the soap-box and presents his manifesto for happiness through logic and clear thinking. I disagree with his logic at one major turning point, but overall the message is good, strong and empowering.
• The Race -- a workbook for learning about flow using the Theory of Constraints. This book is not for the faint-hearted, though thankfully it has no differential equations. Even though I had read and understood The Goal, and applied the ideas in many organisations, The Race taught me some deep new surprises.

I read each of those books again every couple of years, and each time my insights deepen. Goldratt was a true genius, and I'm surprised at how much his death has affected me this weekend.

Long live The Goal.

" I do not view a project as the sum of its code. Rather, it is the view of that code through the tooling that it is designed to take advantage of. By targeting my code towards my tools, I can get a lot of value with a lot less code."

-- Arlo Belshee, setting up the conditions for his mock-free project

This is a nice extension of the idea that code should be "habitable"; that code exists not just to execute, but to be further worked by future developers. I'm very much looking forward to this series of articles from Arlo...

Here's a quick experience report, about something I noticed myself doing this week...

I'm developing a ruby app that's something like a library. I have some code that collects the names of the user's 5 last visited items, which could be books, DVDs, MP3 downloads etc. Right now we only need the items' names, so the collector calls the <code>name</code> method on each object in the collection, and duck-typing does the rest, right?

Well, only if each class of "visitable" thing defines a <code>name</code> method that has the right semantics for this collection. if this were a statically typed language such as Java we'd define a <code>Visitable</code> interface and have classes Book, DVD, MP3 implement it. But this is Ruby, so we don't do that. And yet, when I add another "visitable" class, I need to get those semantics right or else I'll break that collection (or worse, something far away that uses it).

This is where J.B.Rainsberger's idea of contract tests helps out. If I define a set of tests for the contract between the collection and the "visitables", I'll get some advance warning of likely trouble when I add more visitable classes.

In this case, all we need is for the "visitable" object to have a non-nil name. I write that contract as a shared example group:

shared_examples_for 'a visitable item' do
  its(:name) { should_not be_nil }
end

And then check that every "visitable" class implements it correctly:

require 'spec_helper'

describe Book do
  it_should_behave_like 'a visitable item'

  # more specs ...
end

And as if to prove the point, when I added this test to the specs for every "visitable" class, one of them failed. I had a broken collection waiting just around the corner, but the contract tests made sure no-one saw it before it was fixed.

In general, contract tests will be richer than this example. But I think the approach holds good: use a shared example group to "specify" the contract between a client and a polymorphic group of supplier classes.

Here's a nice observation from @mattwynne about vim, which is currently our editor of choice when remotely pairing:

As we become sharper with vim's text-navigation commands we find we're using { and } to jump from "paragraph" to paragraph, and particularly to jump from method to method. So when a method has a blank line somewhere inside it, the } won't jump over the entire method; it jumps to the line break instead.

That's vim reminding us that this method violates the SRP.

"The existence of if statements in this code signals duplication, because the caller already knows which path it wants the callee to follow. In a misguided attempt to remove duplication, the programmer had brought together functionality that didn't belong together, and in so doing had created more duplication."

This is from a blog post I wrote almost seven years ago, called if.... At the time, and in the context of the projects I was working on then, it contains some radical ideas. It's nice to see that they still apply today.

I just briefly reviewed the new Theory of Constraints novel Be Fast or Be Gone here: http://www.goodreads.com/review/show/163157721. 4 stars, mainly for its literary qualities than for its TOC content.

"Do you know that the software you just released has realised the expected value?"

Now that I'm back to blogging regularly again (thus far), I'm reminded of the 500-odd posts in my old blog, many of which won't have been read by new readers, and many of which I've completely forgotten myself. So occasionally I'll dig out one of those old posts and re-publish it here. If I think the old post needs a bit of a re-write, I'll post the revised version here; but if I think the old post stands the test of time I'll leave it untouched and simply link to it. And that's the case with a post from about a year ago, entitled Releasing vs. Delivering.