Friday, January 02, 2009

I don't know

If you read something new that is contrary to your current understanding you are faced with several possibilities:
  1. The new idea stems from a new context which you haven't experienced. In this new context the old idea that you are familiar with no longer applies.
  2. The new idea hasn't been rigorously tested, hence the need to seek corroborating testimonies.
  3. The new idea has been corroborated, but the corroborators are involved in a conspiracy of lies in an attempt to deceive.
Now before you jump to option 3, you would rigorously explore options 1 and 2 first, for the simple reason that you may learn something new. Well at least you would think so.

In my experience this is seldom the case with programmers. In most instances when faced with a new idea that challenges current "best practice", I see programmers jumping to option 3.

This blog post and the comments that follow is a clear example.

So why is this? I think it has to do with how programmers process information. As left brained people, they build ever more elaborate models of understanding of what is "best". New information to the contrary challenges that model and rather then see the model fall like a deck of cards there is a strong impulse to reject the new idea.

I have blogged about this before:
Not knowing shouldn't be threatening, a state that should be extinguished quickly, with ever more elaborate models. No, not knowing is just part of the rich fabric of life. In fact there is power in the unknown. In acknowledging that there isn't a simple formula, order can be found in chaos.
Finding order in chaos is one of the most basic tenets of Agile Development. It is this philosophy that eschews any attempt to be deterministic and know in advance what is best. Instead Agile development embraces an empirical approach of trail and error, suck it and see, where not knowing and discovery is a natural part of the process.

This philosophy seems to be a hard sell. Everyone wants a fixed model, kind of like painting by numbers, which you can buy off the shelf and will solve your problem each and every time. In an attempt to fix the model scepticism is deemed as negative. The vice of non-believers who refuse to "get on message" about what is "best".

Keith Braithwaite takes a contrary point of view. Rather then seeing scepticism as always bad, he believes that healthy scepticism is a good thing, a sign that you are actually thinking and processing new ideas on their own merits. I agree. The problem with 'best practice" and a "fixed model" is that for any non-trivial process "best" is always conditional. So in different contexts what is best will differ. So what is right for one team may not be right for you. So there is no ready formula, and you need to discover what is best for each specific context, which means admitting that perhaps you don't know. This is why you can't master Agile development by just reading a book, and most Agile advocates suggest that you commandeer the help of an experienced coach who has experienced several different contexts to help guide you in discovering what is right for you.

Keith makes his point very well in an interview on InfoQ. At around 24 minutes and 49 seconds in to the interview, the interviewer asks "How do you choose the right Agile management tool if you are new to Agile?". To which Keith answers: "I don't know". From this admission you can actually see a process of discovery ensue. Keith then goes on to say that in lieu of knowing he would suggest using the simplest thing that works, an Excel spreadsheet. After using the spreadsheet for a while and writing macros to automate the calculations you needed you would learn what it is your process needed from an Agile project management tool and would then be able to decide which tool if any on the market best suited you.

It is a magical moment, with Keith shacking his finger in excitement as he discovers the answer to a question which he previously didn't have an answer to. The interesting thing for me is that the discovery started off with the statement "I don't know".

How many of us would respond to our boss when asked a question like "What tool should we use?" with "I don't know"? Very few in my experience. What is more likely is a long diatribe based on our prior context and what the book says or what we've read in reviews. As a consequence the opportunity for discovery is lost.

Take the time to watch Keith's presentation and try saying "I don't know" more often. You may find that it accelerates your learning tremendously.

Further Thoughts:

Alan Kay has another explanation for why people with prior context find it difficult to accept new ideas:


"Kay blames this lack of innovation on the fact that most adults employ instrumental reasoning to evaluate and apply new ideas. This means that adults have difficulty evaluating new ideas because they're carrying too many existing goals, and too much context to be able to see the full potential of new ideas. One way to overcome this problem is to work with children. Children won't know that something is difficult or that hundreds of papers have been published explaining the intricacies of some particular problem. They are more likely to experiment where adults would have given up, and to ask, "So what else can I do with this?"

I think this is similar to my "preserve the existing model" idea, where people reject new ideas that don't fit their established understanding. The same issue is also seen in science where breakthroughs happen during moments when some one is brave enough to go against the established orthodoxy. It is interesting that Alan Kay believes that children don't suffer from this. This fits with the proverb "you can't teach an old dog new tricks". So one solution is to try and maintain a child like curiosity and always ask the question Why? in the annoying way children do. I do this and it works well. If you ask why 5 times, it is usually enough to reveal something new.

3 comments:

Yardena said...

Very nice, the courage to say "I don't know" is probably the most important merit in a developer for me. Of course it has to come along with curiosity to find out the answer. I often do it myself.

It's great to be surrounded by people who are honest and appreciate honesty. When there are "leaders" and "followers", it happens often that the leader (or manager) wants to appear "know it all", even if it's pretense. The subjects, on the other hand, are keen to please the boss, and so they also often put up a show. So everybody's bluffing... The only solution seems to be making people feel equal - partners achieving the same goal. Then they have the right to ask questions, to have doubts, and yet they are fully responsible and accountable for the result, so they can't get away with "I don't know and I don't care". To me this is a truly Agile team.

Also I suppose that the more you know, the harder it is to keep your mind open to new ideas... unless you keep challenging your knowledge all the time :-)

Paul Beckford said...

Hi Yardena,

Thanks for the comment. It is comforting to know that there are like-minds out there. I have had the good fortune to have worked in open and honest teams too, but it seems to be the rare exception rather than the rule, a fluke. At other times I'm left wondering whether I'm the only sane person left on the planet. Or perhaps I'm the crazy one!

You make some very good observations. You mention courage. I agree. People often lack the courage to say "I don't know", when deep down they know that would be the right thing to do. Then there is the whole issue of personal safety in the work place... Getting shot for being honest :(

The courage to do the right thing despite the risks. Sounds like the title of another blog post :)

Paul.

Yardena said...

Looking forward to read the follow-up :-) BTW I just listened to the whole interview - excellent indeed.