January 2010 Archives

I'm learning Ruby these days and after reading the excellent book The Ruby Programming Language I found myself in need of actually writing and reading some code. I tried starting a pet project in Ruby but the, uhm, distractions of two young children made it difficult to get that off the ground and I also quickly realized that I needed some more training before I could get productive on that project.

So enter Ruby Koans written by Jim Weirich and Joe O'Brien of EdgeCase. This little git repo guides (and forces you) through a series of test files with (at first) failing unit tests where you read code and make failing tests pass one after another. It starts out easy with variables and true false and the likes and end up with open classes, message passing and modules.

If you tolerate some zen puns and need a quick intro to ruby and testing in ruby, it's worth a look. The beauty for me was the ease of doing one pomodoro of Ruby Koans each morning and the mental context needed to do that was very small.

I have watched some talks by John Seddon on Systems Thinking and where he feels Lean has failed. Seddon's focus is service organizations in public and private sector like health-care and customer support and sales for various products. But how would systems thinking apply to software development? Have we got it all wrong? I'm going to try and map some of the ideas of Systems Thinking over to existing software development methodologies and practices and see where we end up.

Systems Thinking in a nutshell

Systems Thinking is about seeing the organization as a system and studying it as a system from the view of the customer. Some core ideas summarized:

1. The only plan for changing an organization is to get knowledge
2. Study demand going into the system
3. Differ between failure demand (bug reports, wrong feature and other sources of rework) and value demand (new features/contracts/projects).
4. Study the variability and predictability of the failure demand. Only what is predictable is preventable. Take steps to prevent failure demand
5. Peoples behavior is a product of the system in which they work. If you want to change the people, change the system
6. Train people to handle the incoming requests and let them pull help on the things they don't know how to solve.
7. Don't standardize the work
8. Give the workers the means to control the work and the power to change it.
9. Measure the actual value delivered to customers.
10. The best way to learn counter-intuitive truths is to see and experience them for yourself

The goals are of course to deliver maximum value (the right features at the right time to solve the right problems) to customers in the shortest time frame possible. Sounds familiar? Read on for more in-depth discussion on each of the items in the list.

I thought I would round up a collection of links that interested me the past few weeks on various topics. First off: NoSQL databases:

• An almost impossibly detailed run-down of NoSQL databases: http://www.vineetgupta.com/2010/01/nosql-databases-part-1-landscape.html. Part 2 should be good too.
• Slides from a talk by Emil Eifrem of Neo4j on the different types of NoSQL databases: http://www.slideshare.net/emileifrem/nosql-east-a-nosql-overview-and-the-benefits-of-graph-databases
• Update Emil Eifrem mentions in his blog post in the comment another very nice overview of the NoSQL ecosystem by Jonathan Ellis of Rackspace.

Then over to Lean and Kanban. Henrik Kniberg and Mattias Skarin just published a new book on InfoQ titled "Kanban and Scrum - making the most of both". If you´re not familiar with Henrik Kniberg´s work, I also suggest "Scrum and XP from the trenches". Erling Wegger Linde´s "A Kanban brown bag recipe" is also worth a read.

And in the spirit of Lean: There is a video of talk by John Seddon of Vanguard titled "Cultural Change is Free". Mainly about systems thinking in the public sector, but private sector aren´t infallible either. Seddon often criticize Lean for being wrong in many places, but I often feel he is criticizing a wrongful implementation of lean ideas, much the same as scrum is often criticized for the misgivings of wrongful implementations. Or rather he is criticizing the tool focus of a lot of lean consultants not the lean principles themselves. And he stresses the differences between the Toyota Productions system and other kinds of organizations. You could also check out is talk "Re-thinking Lean service" on InfoQ which deals with the same topic in a slightly different packaging.