Category: Basecamp

Survivor bias: an experiment

August 4, 2014 /

I write a simple computer program that randomly selects one of two outcomes. I send out letters telling people I can pick stocks and shares that will go up. About 50% of the people I write to think I know what I’m doing and think they might buy subscriptions to my stock picking service.

I do the same thing with the 50% that got the right answer, each time making an ever smaller group think I’m a stock picking genius.

Eventually I will run out of people, but right up to the last two it will appear to them that I really knew what I was doing, when I was effectively tossing a coin.

In the mean time quite a few of them may have subscribed to my stock picking service. Good for me, not so much for them.

The people at the end of this chain of probabilities will think that they are kings of the world, when they are only survivors of a simple process that could have picked anyone from the original group of stock buyers.

I recently attended a virtual course on complexity and discovered the fun simulation language Net Logo. For historical reasons the little actors displayed on the screen are called turtles. I could just as easily build a program that has a population that halves every turn. Is the lone turtle left blinking on the screen at the end a special turtle, did it somehow avoid the grim reaper against the odds? No, obviously not.

If that turtle was instead a person? The story it had to tell would be a story the rest of us would want to emulate because it was a survivor. This is why the biographies of the heroic entrepreneurs are often not that surprising. This is why their opinions quite often don’t differ a lot from those of others in the same cohort.

I used to work for Oracle and read the unauthorised biography of Larry Ellison – it’s an entertaining read and certainly not very complimentary. One of the things that comes through is luck, Oracle came close to going over several times, literally so close that a single large order from Japan saved it. I was talking about Richard Branson with someone recently. If I remember it right he originally had the idea of opening his record stores near tube stations late at night so people travelling home could buy records, he also had an aunt who lent him the money to open these stores. Great idea, but he didn’t have to go to a bank and get laughed at. Again, when Steve Jobs early Apple got some venture capital so they could make things happen – whoa, things started happening! (Thanks to Tim Spencer for this one).

There is an unknown population of other people and businesses that didn’t make the cut, or that stayed small service companies that are still around but not mega corporations. Probably 99.99% of them. Jobs himself acknowledged this with the famous analogy that the things joining the dots together are only apparent when you look back and make a story of them. In my last post I talked about pareidolia, which is the human tendency to invent patterns where none exist. We can all find stories up like this; if I hadn’t answered a job advert in the Independent I wouldn’t have met my wife, my kids wouldn’t exist and, like, wow man (sarcasm off). We make a causal chain of events but forget the massive part that chance plays in what happens to us. If the University had placed the ad in a different paper on a different day, who knows?

Survivor bias makes the winners’ stories compelling, but there are another 9999 (or many more) stories of other people we never hear. Remember this, next time someone tells you that you must emulate this or that hero of theirs. Success needs an element of luck, and the same person may not be lucky twice. Napoleon used to ask of a general is he lucky? He was no fool. We all love 37 signals’ (now Bascamps’) story, but there was luck there. Lots of people have tried their formula without getting what they have, or even losing everything.

This isn’t meant to sound like a doom and gloom principle, far from it, what it is saying is you need to find your own way that works for you. You also need to take that opportunity when it falls into your lap and do something with it. But you aren’t any more special than anyone else. It doesn’t matter. What matters is being clear about what you want and sticking to it.

Why I hate todo list apps

July 5, 2014 /

I recently had a twitter discussion about why I don’t like using Basecamp.

It’s a bit weird, I love Rails and it originated from the need to create a stable framework to create Basecamp. DHH and his colleagues were generous enough to share it with the rest of us and I’ve been using it for years to great effect. I admire DHH and the guys at the company and have read their books. But I hate their product. Using it makes me feel depressed.

I can’t see the flexibility others see anywhere. They are a poster child for great design and easy UI and it’s pretty dull and obvious, maybe that’s what the fuss is about. I’ve used it off and on for years and it doesn’t seem to have substantively changed in all that time, yet there are allegedly changes and improvements happening to it constantly. It’s also boring, even more boring than the bazillion sites you see built on top of Twitter Bootstrap – because they usually have some metaphor the coders are exploring and bootstrap’s a quick way to make it presentable while they experiment.

But the main thing is I can’t stand todo list apps.

This comes out of the way I work and think. I will write todo lists on paper and cross them off, but for anything bigger than just me (and up to 5 items) I need to visualise it and look at the flow and commitment of work. You can’t do this with static text-based lists without doing a lot of counting in your head. As far as I can work out you can’t create a different visualisation (in Basecamp) where you have a private list taken from other lists of things you care about today in the order that matters to you without creating another list that isn’t linked to the original tasks so you’d have to close everything twice. It hasn’t changed in years.

In the physical world you can do this with sticky notes or file cards and a bit of blu tac to put each piece of work into something that can be visualised and moved about. It doesn’t have to be complex, but nicking ideas from scrum and kanban around allocating points for pieces of work and limiting your work in progress (WIP) you can come up with something that lets you look at your pipeline and your commitments so you can start to have grown up conversations with other people about priorities and schedules. Limiting your WIP also gives you a far better chance of actually getting something worthwhile done. This is a big win over boring lists, but harder to understand at first.

Todo lists are, I think, a great tool for linear thinking and controlling.*

The metaphor lists give you is the linear instruction manual, codes, all you can do is change their priority and create more items. They also suffer from being unbounded, so you can just keep adding to them and never finish. There’s a very interesting time management book by Mark Forster called Do it Tomorrow. In it I found the idea of a closed list. This is a list you don’t add to and work on until it’s done – he’s discovered this makes you more productive and also you start tackling the tasks you really don’t want to do because you can’t close the list off until you’ve done them. This is a great antidote to procrastination. It’s also limiting your WIP. In fact it’s a different take on the same idea as a personal productivity booster.

So, in essence, for me the list metaphor stifles your ability to think and visualise without a lot of effort breaking out of the mental straightjackets it puts you in. There are better metaphors that allow you to easily move work about and discuss it properly with stake holders. So use them a little for small tasks, but for the big stuff – use bigger metaphors. I also think gantt charts cause similar cognitive blindness when you use them for anything other than checking if you are still on track.

* Aside: I was going to use the phrase command and control. The original meaning of this was simply that military operations have a designated officer who is responsible for seeing the mission through. How that officer does it is not defined. Some systems thinkers, for example John Seddon, use this term to mean enterprises where the people doing the work are not expected to show any initiative and be told what to do all the time so everything costs a fortune and is badly done by people who could do a much better job if left alone to do it properly. Military operations don’t work like this, people are trusted to do what their training tells them so they can achieve their objectives, see commander’s intent. Seddon’s meaning seems to have triumphed in systems thinking debates, however.