zaterdag 14 december 2013

What do startups have in common with split brain patients ?

Despite all the promises of all software methodologies we still struggle with large software projects. Why ? Because of the way our brain is wired, we fall time after time into the same cognitive traps. Test driven development and validated learning as proposed by the book the lean startup are different. These methods use a more science based approach which give us direct feedback about our assumptions.

Let's start our journey with the root cause - our brain.

The phi phenomenon

There two spots on a screen. One spot is red, and the other is green, and the spots are alternating rapidly on a screen. You will see a orange spot in the middle, moving from the left to the right. It is an illusion known as phi phenomenon.

The phi phenomenon is an illusion of time. This experiment raised some interesting philosophical questions. Our consciousness produces the moving orange spot before the green spot appears. Is the orange spot predicted or does our brain an interpolation ? The orange spot is an experience which is the result of an interpolation done by our brain. First the sensory input (the green spot) is processed, and afterwards you become aware of the orange spot. Mind boggling isn't ?

Consciousness is the top of the ice-mountain which sticks out the water. It is as a end result, not a starting point. It is a process that integrates all sensory input, mixed with input from our emotional centers and attention filters. On top of that integration process a story is constructed by the left hemisphere. A story to make to make sense of the world. But under the water - 90% - all the actions takes place.

The left hemisphere orders the world

In split-brain patients the two hemispheres cannot communicate with each other. Roger Sperry and Michael Gazzaniga did subtle experiments with split brain patients to investigate the differences between the left and the right hemisphere. From these experiments Gazzaniga postulated the interpreter theory. It says that the left hemisphere orders the world by inventing reasons and causes. If the left and right hemispheres of a split brain are presented with conflicting information, the left hemisphere resolves the conflict by inventing a causes or a reasons.

This process of conflict resolving happens all the time in our head, it is automatic and unstoppable. If you present a human with a serie of random numbers, he keeps on puzzling until he finds a pattern. Our brain is hooked on finding patterns, reasons and causes. This is called apophenia, and which causes gamblers to think that there is a pattern in roulette (the gambler’s fallacy).

Risk assessment

I advise to read the bestseller Thinking, Fast and Slow of Daniel Kahneman. The book debunks many myths about ourselves. The chapter about the public perception of risks research by Paul Slovic gives some compelling examples. Studies show how judgements about risks are influenced by media coverage. For instance death by a tornado was seen a more frequent death cause as asthma, while asthma causes 20 times more deaths. People are bad in predicting the outcomes of rare events, like earthquakes, flight accidents, terrorism. The more terror we perceive, the higher we estimate the change of the event.

We cannot predict outcomes when working in chaotic, complex environments like software projects. When confronted in situations without enough information, our left-hemisphere invents automatically causes and reasons, and we have a strong preference for answers which match our emotional reactions. And worse - we do not recognize that the reasons and causes are invented by our brain. To us they are real, a tunnel effect which Kahneman calls "What you see is all there is (WYSIATI)". According Kahneman our brain contains a machine (system 1) for jumping to conclusions.

Traditional planning and management techniques are failing, because these are based on the assumption that we are rational agents. We can put this view in the trashcan. It is seriously flawed.

Invalidate your assumptions

Many software development methodologies are developed to mitigate the risks of software projects. Most of the methodologies work only in a certain context and in a predictable environment. But there is an interesting exception. Test Driven Development (TDD) is regarded as a good development practice. A software engineer first writes a number of small tests and then writes the code. The tests validate the code, and vice versa - the code validates the tests. It always surprises me if I have to change the unit tests, because my original assumptions were not correct. Test driven development is a process of validated learning.

Validated learning means test our assumptions with experiments, designed to invalidate our assumptions. Read well - invalidate. To prove that your are wrong. The whole scientific revolution is based on this principle. It is the most effective way to avoid the cognitive biases of our brain. People can really learn, but only if they get direct feedback about their assumptions.

Jez Humble writes in his essay "Why software development methodologies suck" that short release cycles and increased feedback are the only two principles which actually work. I tend to agree with him, but only if you invalidate your assumptions. Even with 20 releases every day we are able to run in a treadmill of wrong ideas about what the customer wants.

Validated learning and the Lean Startup

The book Lean Startup of Eric Ries explains how validated learning helps startup companies in finding the right product for the right customers. The book goes into detail how measuring techniques like cohort analysis and A/B testing can be applied by start-ups. The same scientific approach as Test Driven Development is used. First you make an hypothesis, then you design a test, build the product and you validate your hypotheses. You may call it test driven business development. This process is called the build-measure-learn loop.

I think that less startups will fail if they apply validated learning as a core principle. It is the power of large numbers. The Harvard study Why the Lean Startup changes everything published by Steve Blank explains why the impact of the Lean Startup will be large on the software industry.

Conclusion
In conclusion, the cognitive biases of our brain is one of the root causes why it is so difficult to build software. With the current insights about our brain functioning it is clear that current management theories about humans as rational agents are seriously flawed. A more science based approach of making hypotheses and doing experiments to invalidate your assumptions can overcome our cognitive biases. Because Test Driven Development and the Lean Startup methodology are using this approach I think these methods have a large impact on the success rate of software projects and startups.

I will end with the famous quote of Albert Einstein:

“Problems cannot be solved with the same mind set that created them.”

References:

zondag 24 november 2013

The holiday of Albert Camus

The struggle itself towards the heights is enough to fill a man's heart. One must imagine Sisyphus happy.

zaterdag 16 november 2013

The value is in the learning

Devops is the new buzz word, and management and business have now adopted practises of mutual collaboration between Dev and Ops, with of course at the end of the rainbow waiting the golden promise of continuous delivery of software. The article The convergence of devops gives a nice overview of the history of Devops.

Because I have a background in both QA and software development, I am working at customers of Hippo in a Devops role. This week I joined a one day conference in Amsterdam about Devops to find out what's the current state of affairs.

Most speakers addressed Devops from a cultural and collaboration perspective. For instance Matthew Skelton spoke about the practises of Run Book or operational manuals which can be a starting point of conversations between Ops and Dev teams. From personal experience I learned that the best collaboration tool is actually ... Skype! So many deployment we did with Skype sessions. Not even mention the debug sessions to solve production problems. It was funny to see one of the conference attendees having a Skype session open during the conference ... maybe solving a production issue ?

What is the gain of Devops for a software developer ?

One of the speakers told that he heard a developer saying "I just want to write code". In his opinion that was not acceptable. But I can understand the remark of the developer. Developers are usually hired for coding. It may be quite a shock if that implies that you have to assure that the code runs on a web server with two million page requests. And that you have to do the testing and help the Ops people in long nightly Skype sessions during deployments. Big change.

This is an important issue - in my opinion - when an organization tries to adopt Devops. Not only business should profit from it, but everyone involved should see the gains.

Actually many of the questions in the conference were actually about a single question. How to inspire the people do jump out of their silos and collaborate? There are no simple answers to this question. The general feeling I got from the conference is that everybody is struggling. We are struggling with something that is bigger than us.

There is change in the air.

So, let's talk about change. I saw two webcasts from Eric Ries which gave me new insights, energy and inspiration.

Eric interviewed the founder of Extreme Programming, Kent Beck. Remarkably, Kent Beck admitted having difficulty to adapt to the Facebook culture of "move fast, break things". He had to learn to be bald again and to build things that have impact. And during the conversation Kent gave an answer about this pounding question raised in the conference. It is so incredibly cool to release yourself your code to millions of users.

Developers ! That is the gain of Devops ! Releasing stuff to millions of people. Funny that nobody in the conference came with this answer ...

Also Kent explained that every working method or practise only make sense in a particular context. For example the Facebook culture would not make sense in Apple. This importance of context was expressed very well by Niek Bartholomeus at the Devops conference. He talked about how devops in mature IT organization is different than in a start-up. Good point.

But what when our environment is changing? Most changes are not coming from ourselves, but from a rapid changing world. For example read this article and think about it.

Actually what I learned - and I have to repeat this lesson again and again to myself - that there are no definitive answers. The only thing we can do is learn every day. Because the value is in the learning and not in the result.

This remarkable statement was done by Eric Ries in the second webcast I saw this weekend. This talk was about how to work in an environment with extreme uncertainty. Innovative start-ups. It is impossible to summarize this talk, you really have to watch it. Mind blowing. I was surprised by the attitude of testing and experimenting and learn from experience. Eric gave an example of a small mobile company. Their whole production process was basically designed as weekly experiments. The deploy on Friday, and they test the new experiments with their own mobiles in the weekend at home. On Monday they evaluated and started new experiments for the coming week. No backlog, no product owner, no plans. Only experiments and tests. Cool.

Now I have the feeling that in Europe - with our social security and social laws, holidays and mature industry - we are arriving at a point that we really have to switch our chip.

Adapt, learn and experiment !

Links