“The society that separates its scholars from its warriors will have its thinking done by cowards and its fighting by fools.”
Archive for November, 2010
When I was small I used to have a soft toy puppet version of Gordon the Gopher from TV’s Going Live!
As Gordon was a fairly large part of my then life, I went to all lengths to make sure he was fully integrated into the family. Part of this involved me building Gordon several miniature versions of common house hold white goods. The Gordon sized versions were mainly built from Toothpaste boxes, old sewing thread spools, straws and colored card. He had a washing machine to wash his various different coats, a vacuum cleaner (unfortunately Dyson had not invented his yet so this was just a plain old Hoover style one) and finally, in a fit of reality, racked with concern that he did not have anywhere to relieve himself, I built Gordon a toilet. The toilet was a fairly anatomically accurate recreation. It had a bowl, a cistern, a pipe connection to the cistern, and a small flushing handle.
What does this have to do with anything? Well recently I was lucky enough to come across this:
What the Fuck is this?
I can hear your brain exploding now.
Yes, that’s right my friends. This image here. This, is the future of toilets. The cisternless toilet.
One must assume that the reason for a cistern, comes from tradition. To get an effective bowl clean, a reasonable water pressure is required. Maybe in the past common households did not have this water pressure available which lead to the design of the high-up cistern, which then was moved down to the low down cistern. But now, in modern days, actually all that’s required is a simple valve to the local water system, that is controllable by the operator.
So where the hell am I going with this?
This problem is a brilliant illustration of a common modern day coding problem. The problem, at the beginning of a project you have certain constraints (i.e. low water pressure), then someone designs a system (i.e. the high cistern) to deal with this problem. Then someone designs a better system (the lower cistern), and then someone else designs a better more efficient but more complicated system (the cistern with two buttons for different flush types). But in reality, all that is needed is time, to wait for the constraint to be resolved, and then careful thought on what is actually needed, in this case, the simplest most elegant solution is just essentially a on/off tap.
This is why I call it the Google toilet, because it’s simple, elegant, robust, easy to maintain and repair, and it does exactly what you need it to do, without complicating the matter by giving you different options and choices to make (do I need a big flush or a small flush? hmm let me evaluate…). It reminds me of a talk on usability given by Aza Raskin of Mozilla:
Another great talk from the Simon Pegg of software. Don’t know how I missed this one and it’s slightly depressing that he was discussing this stuff back in 2007 and now it’s 2010. But anyway, I think his point about Lean production line development and software developement being different and more like car design development are very important and echo’d in the Poppendieck books. So sit down, get a cup of tea and take half an hour to watch this talk.
I really like this Ted talk. I think when you think about it everything is a game. In that the definition of a game is a set of tasks that someone has to complete.
A very poorly designed game is called ‘everyday work’. A game where the reward levels are set too steeply. The rewards themselves are poorly thought out, the variability is low and worst of all it never ends.
It reminds me of a passage from the book “the one minute manager” by Ken Blanchard and Spencer Johnson.
“One night, for example, I was bowling, and I saw some of the ‘problem employees’ at work from my last organization. One of the real problem people, who I remembered all too well, took the bowling ball and approached the line and rolled the ball. Then he started to scream and yell and jump around. Why do you think he was so happy? Because he got a strike. He had knocked down all the pins.”
The rest of the book goes on to discuss that feedback is the difference between most work and the game. I think it is a little more complicated than that as the video above points out there are a few more reward mechanisms in place. But essentially the point is correct. Imagine if your job was as rewarding as a computer game or bowling? Everyday people would be happy to go in. This is how it should be, and it’s not a case of some people being lucky and some people being unlucky, it’s a case of job & reward design.
It’s interesting because I think some of the most compelling jobs are the ones where the design of the job is incremental and well thought out. Programming for example can be a very frustrating but reward experience for some people. The process of learning very small pieces and then being able to combine them to produce something much greater can be intensely rewarding. It’s very similar to a game we get small rewards for effort and then finally one large reward once enough time has been put in. The question with programming is where does your tolerance level lie? Some people have the patience to learn C++ without giving up at the more difficult hurdles like Malloc and pointers where as some don’t have that patience and are more adept at learning PHP.
Social jobs, for example counselling can also have a similar cycle but requires different skills, but essentially you see the same progression of small incremental rewards leading to a much larger reward.
My final great example of this is blogging, I wonder how many people would have a blog, if for example you didn’t have statpress to show you how many visitors you got per day?
So maybe tomorrow when you go into work, think about the design of your job and what you could do to knock down all the pins…