Slow motion velocity/wip game

I've noticed when teams play the velocity/wip game they tend to focus a lot of their energy on learning how to throw their dice faster. Learning to throw faster means you'll throw more 1's during your 1 minute iteration but that isn't really the point of the game. It also means that comparisons of velocity between different iterations are misleading.

Thinking about this today I suddenly thought of a two simple ways to improve the effectiveness of the velocity/wip game...
  • Instead of having a 1 minute iteration have a fixed number of rolls per iteration. Eleven say.
  • Do each roll in slow-motion. After each player rolls their dice, count up the 1's then slowly and calmly discuss how to play those 1's on the current board. Then make the play. Then repeat.
I tried it today (hi Michelle, Lee, Brian, Kenny, Marty, Jarlath, Gerard, Tony, and Charlie) and the difference was startling. Instead of trying to increase their velocity, the team worked on learning to play the game better. So much so that they actually forgot to measure their velocity!

I wish I'd said that

is an excellent book by Maurice Silver (isbn 1-86105-285-5). As usual I'm going to quote from a few pages:
Advice is like snow - the more softly it falls, the better it takes hold.
Don't wait for your ship to come it; swim out to it.
A stumbling block is a stepping-stone that you tripped over.
Make a point to do something each day that you don't want to do.
Error is the discipline through which we advance.
Men inevitably become indifferent to anything they do often.
There can be no economy where there is no efficiency.
When you are through changing, you're through.
Fear is like a darkroom where little doubts gets developed.
The mind grows rich from what it receives; the heart from what it gives.
It is not doing the things we like to do, but liking the things we have to do that makes life pleasant.
Do not look where you fell but where you slipped.
Rudeness is the weak man's imitation of strength.
The instant we feel anger we have already ceased striving for truth and have begun striving for ourselves.
If you can find a path with no obstacles, it probably doesn't lead anywhere.

Pragmatic thinking and learning

is an excellent book by Andy Hunt (isbn 1-934356-05-0). As usual I'm going to quote from a few pages:
Being happy broadens your thought processes.
Are you fixing the problem or fixing the blame?
Reading is ineffective compared to any sort of experiential learning.
Documenting is more important than documentation.
Learn from similarities; unlearn from differences.
Your creativity suffers on the day your under the gun and remains suppressed for the next two days as well.
Create an environment where the cost of failure is near zero.
Much of perception is based on prediction.
Every read of your memory is really a write.
Inaction is the enemy, not error.

In the brain of Jon Jagger - Deliberate practice

Here's a video (and slides) of my SkillsMatter Deliberate practice talk. This is a much extended version of the 97 Things lightning talk I did at Javazone recently. I've been known to break cameras and mirrors in the past so they wisely filmed it in very low light... :-}

JavaZone 2010: 97 Things Lightning Talk - Do more deliberate practice

Here's a video of the lightning talk - Do more deliberate practice (one of my entries in the book 97 Things Every Programmer Should Know) I did at the recent Javazone conference. It's about how deliberate practice relates to agility.

cyber-dojo video - Roman Numerals Coding Kata in Ruby

Here's a video of me demonstrating the cyber-dojo website by doing the Roman Numerals kata in Ruby.

Rethinking systems analysis and design

is an excellent book by Jerry Weinberg (isbn 0-932633-08-0). As usual I'm going to quote from a few pages:
We don't need another "movement" just now - unless it is something analogous to a bowel movement - something to flush our system clean of waste material that we've accumulated over the years.
When dealing with the unknown, it appears to be better to handle one situation at a time, examine the results obtained, and then prepare a plan for the next situation.
How to master oneself? The Eastern philosophers have always understood, but it seems the most arduous lesson for us westerners. One masters oneself by giving up the attempt. By approaching an interview with the attitude that one cannot be absolutely in control, one attains the utmost possible control.
One of the greatest divisions [of human thought] is between static and dynamic schemes, between thing and process, between noun and verb.
The architect without the stonemason is not designing cathedrals, but castles in the air.
The way things are is always fighting with the way things might be.
The rough sketch has several advantages over the precise drawing: it represents less investment in time, so we're not afraid to throw it away and try something else; its very roughness conveys important information about where we are in the design process.
The ability to decide when to stop is a feature not a failure.
90% of aggravation in programming projects comes at the end.

Accu london cyber-dojo

The London chapter of accu held a cyber-dojo last week. It was hosted by the excellent people at SkillsMatter. The group agreed to try the Roman Numerals kata with three laptops using Java and one using C#. Everyone had lots of fun. Thank you to everyone who helped to make it possible.

Existentialism and Humanism

Existentialism and humanism is an excellent book by Jean Paul Sartre (isbn 0-413-31300-X). As usual I'm going to quote from a few pages:
There is only one sin, and that's failing to believe you have a choice.
I should be without illusion and I should do what I can.
Many have but one resource to sustain them in their misery, and that is to think, "Circumstances have been against me."
What produces cowardice is the act of giving up.
I cannot obtain any truth whatsoever about myself, except through the mediation of another.
What is not possible is not to choose.
We define man only in relation to his commitments.
The content is always concrete, and therefore unpredictable; it has always been invented.

Barbel fishing on the River Wye

Caught on sweetcorn on the Whitehouse beat. What a beautiful river. And what a beautiful fish.

Two bowls

My I Ching for today was no 41 Reduction. Part of it reads:

Two bowls can be used for presentation. The two bowls must be timed appropriately: reduction of firmness and increase of flexibility have their times...

I was struck by how apt that is for software development. A reduction of firmness mirrors abstraction. But abstractions must be grounded by experience. By reality. It conjurs an image of periodically moving the work back and forth - between firmness and flexibility. It's also reminiscent of how code and its tests help to shape and form each other.

Understanding the professional programmer

is an excellent book by Jerry Weinberg (isbn 0-932633-09-9). As usual I'm going to quote from a few pages:
To be a champion kicker requires about one hundred parts motivation to every one part leg.
The professional programmer is a person who solves problems for other people - whatever that takes.
I believe that terminology eventually influences our thinking.
Health comes before all else in producing happiness.
You must begin to see change as something wonderfully rare, and worth observing. You must stop taking change for granted if you wish to master the art of productive change.
Many programmers… work in environments in which they receive essentially no real feedback embodying the consequences of what they do. Lacking no real feedback, they lack the motivation to attempt changes, and they also lack the information needed to make the correct changes.
The number-one problem of both analysts and programmers - as well as their managers - is that they assume too much. They especially assume that they know what kind of problem they're working on - that it's a puzzle and not a problem.
Brains require stimulation.
The secret key to all good writing is re-writing.
As long as the bull lives, there will be bullshit.
Lines of code is a measure of the solution and not the problem.

Speed and steering

In a previous visit to Tandberg (now part of Cisco) I happened to mention I once learned to ride a unicycle. During my latest visit to Tandberg a developer called Oivind told me he unicycled to work and asked if I would I like to try it again. It had been 25 years but I was game.

I started by moving slowly along a fairly narrow corridor - narrow enough to touch both walls. I managed to get some of the skill back but quickly reach a plateau. Oivind suggested I try riding in the open space at the end of the corridor.

With more space I could concentrate on leaning forward and riding a bit faster without worrying about crashing into a wall. Going a bit faster is important because it's hard to maintain balance moving very slowly.

With more space I could concentrate on keeping going and steering into a correction without worrying about crashing into a wall. Steering is important because there's not much point in learning to ride if you can't control where you're going.

an interview with Jerry Weinberg

If you were stranded on a desert island with five books which books would you choose and why? Please don’t pick more than one of your own!
  • An empty notebook with as many square feet of blank paper possible, for keeping my journal of this desert island adventure.
  • The complete Oxford English Dictionary, so I can study the English language in depth for the future when I might be rescued.
  • Frazer's Golden Bough, so I can immerse myself in the vastness of human culture.
  • Martin Gardner's The Annotated Alice (Lewis Carroll's Alice books, annotated by Martin Gardner) so I could read for wisdom and humor at the same time. (I've used this book as a text in s/w development.)
  • If a Kindle counts as one book, I'd take that. Otherwise, Wilderness Medicine, Beyond First Aid, 5th Edition by William Forgey (I'd like to research this one, because I haven't read this, but I would need the best such book.)
I don't have any computer books on the list because I'm assuming I wouldn't have a computer. If there were such a book, I'd probably want *How to Build a Two-Way Radio Out of Coconut Shells*.
Which books would you change and to what if you did have a computer?
  • I would not need the empty notebook, as I could keep my journal on-line. Instead, I'd want a complete service manual for the computer equipment.
  • I would not need the OED, for the same reason — an on-line OED. Instead, I would take Don Knuth's The Art of Computer Programming. I assume we count all published volumes as one "book."
The rest I would keep the same.
What do you consider your biggest contribution to the software world.
That's easy. I answered that some years ago, and my answer hasn't changed. My biggest contribution to the software world is that I never invented yet another programming language.
What would you still like to achieve?
I'd like to persuade more computer people to work on the unsolved problems of our profession, rather than the (pretty much) solved ones such as compiler writing.
Could you give some examples of what you consider to be the important unsolved problems of our profession
  • requirements: finding out what will really make people happy
  • doing the things we know we ought to do
  • not doing things we know we ought not do
  • conservation of knowledge from one generation to the next
  • developing some sense of standard practice (can be more than one, but not too many) that will be followed around the world

You’ve written that you get a lot of inspiration from nature. Could you give some examples - of both the inspiration and nature that inspired it.
If you had a one-time-only time machine how would you use it?
I wouldn't. I have a rule: Don't mess with time.
Suppose you used it to visit your younger self what advice would you give yourself?
When someone offers advice, you ought to taste it, but you don't have to swallow it.
In question one you mentioned Martin Gardener’s book, The Annotated Alice. Could you expand on how you used this as a text in s/w development.
Alice's trip across the chessboard to become promoted quite nicely parallels a typical development process. It's no coincidence that Lewis Carroll (Dodgson) was a mathematical logician. He was able to do logic, and to make memorable the instances of illogic. For example, the Red Queen's behavior is that of many bad development managers ("Off with their heads.") The students were invited to find other parallels in the book, which hopefully set their minds to work.
What is the biggest change you'd like to see in the software world?
Slowing down in order to do things right.
What would it take to make this happen?
Hell would have to freeze.
What question would you ask yourself?
What question would you ask yourself?
And what is your answer?
What question would you ask yourself? Just kidding. That was a fun recursion.
[this is the real question Jerry would ask himself] Why are you writing novels these days?
[and this is his real answer] Like any life-changing decision, the switch to fiction has many reasons, all intertwingled. What follows are some of the reasons I have been able to disentangle.
  • All my life, I've dedicated myself to helping smart, talented people be happy and productive. You can see that theme in my books, I think, and it's the theme I've continued in my novels (see list below).
  • But not all my work has been through writing. Dani and I have also spent our careers training these smart, talented people through the use of experiential workshops — Problem Solving Leadership Workshop (PSL) Organization Change Shop (OCS), Systems Engineering Management (SEM), and the Amplifying Your Effectiveness Conference (AYE). We use experiential training methods because they are effective. They reach many people, and much more deeply, than your typical lecture class with PowerPoint slides.
  • In many ways, reading a non-fiction book can be much like one of those PowerPoint lectures, so whenever possible, I have used stories to bring my non-fiction works to life. Stories have always been powerful for learning, going back thousands of years. Why? Because a good story arouses the readers feelings of participating in the experience the story describes.
  • A great deal of the popularity of my books (and other non-fiction writers like Tom DeMarco) is in the stories. They make for lighter reading, which some people love and some people find objectionable, but overall, I have managed to present lots of hard stuff effectively through these stories.
  • Some of my books have been directed specifically at Information Technology (IT) people. Some have not. Generally, the ones that have sold best and longest have been the ones not so specifically directed at IT people — books such as These readers tell me they like the stories, even those that have some technical content. In fact, they often learn technical concepts and details as a byproduct of reading and enjoying the stories. I like that, because it says I have reached many smart, talented people who don't happen to be IT folk. The novels do that even better. I hope more people try them.

Could you briefly mention some of your favourite music and films.
Music: Almost anything Baroque. Any of Mozart (I have the complete recordings of his works, which should tell you something). Most music prior to 1850; almost nothing after that except Sousa, Gilbert & Sullivan, and Scott Joplin.
Films: (I'm probably missing some, but all these are favorites that I can see again at any time, with no hesitation.)
Could you expand a little on your rule "not messing with time"? Does it relate to "Slowing down in order to do things right?"
Yes. Things take the time they take, not the time you hope they will take. Pushing for half-time produces half-baked.
At your Problem Solving Leadership course I noticed you sometimes answered a question "obliquely". For example when discussing cancer treatments you told the story of the Aspen mountain passes and how none of them are really much good. Could you explain why you sometimes choose to answer a question in this manner.
What you call oblique, I call powerful. Take your example. Few of my listeners have had cancer, but many of them have the experience of hiking on difficult trails. Thus, the lesson is more likely to stick, as it has with you.
You’ve said learning a new language (a human language, such as Spanish) really helped your ability to think in a Systems Thinking way. Could you expand on that?
In my case, it was French, learned while living in Geneva for a number of years. After a while, I found myself thinking in French when my ordinary thinking wasn't solving a problem. For instance, in English we say things like, "I took an aspirin for my headache." In French, the expression would be "against my headache." To me, that seems to imply something different from the English expression — a different way of thinking about disease and cure.
So, in effect, after learning French, I have a second way of addressing problems — and once I have a second way, it's easy to see that there may be a third way, and a fourth way, and so on. Being able to see a situation in multiple ways is a key concept in systems thinking, and learning a new language favors that concept.
The same phenomenon occurs in so-called programming languages. Someone who can work in only one such "language" cannot truly be considered a real programmer, in my opinion. That's why in school, I always insisted that programming homework be done in at least two languages — along with a written analysis of how each language affected the way the student approached the problem.

Many thanks to Jerry for agreeing to be interviewed by me. Fiona Charles took the excellent photo of me and Jerry. If you're a fan of Jerry you should check out her excellent book The Gift of Time. This interview also appeared in CVu, a publication of the ACCU, an organisation of programmers who care about professionalism in programming and are dedicated to raising the standard of programming.

Quality Software Management
Vol 4. Anticipating Change

is an excellent book by Jerry Weinberg (isbn 0-932633-32-3). As usual I'm going to quote from a few pages:
Organization inhibits reorganization (Minot's Law).
Growth is always non-linear.
Stability is the ability to ward off change.
A measurement system helps makes the software product visible.
Things will only get less visible over time.
Measure process not individuals.
Never use loops in a process description.
You need stability in order to make improvements.
Testing to improve, not to prove.
Without constant tending any process will deteriorate.
In a feedback control system it's only our perception that determines which is controller and which is controllee.

A day of deliberate practice

A Day of Deliberate Practice is the name of the JAOO conference tutorial session that Kevlin Henney and I are looking forward to running on Thursday 7th October. We've done some detailed preparation for it and think it's going to be really great. We will be using deliberate practice to try and increase the personal and technical agility of the participants.

You can get a 20% discount on the three conference days. Simply follow either Kevlin or myself on Twitter and then use “JAOOspeakerfollower” as promotion code upon registration: