How to get it wrong more often

I don’t like to get stuff wrong. I hate it when I realise that I’ve rushed in and built something that just doesn’t work perfectly.

It’s partly embarrassment (maybe I made a basic error in logic, or made a false assumption, way back at the beginning of a long project, and now it’s becoming obvious. And now I just need to spend 5 days to patch it up so nobody notices).

It’s partly excitement and impatience (at each little decision point, it’s always tempting to take the shortest path to the next point. Then you see ‘progress’. Of course that’s just like wandering from the tree right in front of you, to the closest next tree in the dark woods – you make progress but it’s random. And you lose sight of the woods).

And then there’s the deep, dark, debilitating fear that something might be wrong. You know how it is – you’re motoring along, building this awesome software solution, and you get the vague feeling that you’re having to write much too much code, to make exceptions, to kludge rules, create weird temporary database tables. While there’s nothing actually wrong, it’s just that everything is not seamless like it should be. But you keep on going.

How to avoid the shit hitting the fan.


Look at how a portrait artist works. They start with a rough layout – a prototype rendering that shows roughly the direction she’s headed. At this point, if it looks wrong, it’s easy to start on a fresh piece of paper.

Next, the most important features are added. She might show it to her client now, who could say “Nope, I want it facing the other direction”, or “make the hair longer”, or even “but I asked you for a picture of a cat”. At this point, it’s easy to start on a fresh piece of paper.

The other approach would be to start on one side of the paper at very high detail, and continue until finished – without stepping back and everyone taking a look. More often than not, the perspective will be a little bit odd, or the colours don’t quite flow, or it’s not cohesive.

Treat your mock-ups and prototypes the same way as an artist treats their initial sketches – as something you can screw up and throw away, until you’re definitely on the right track, and everyone involved is happy with the direction.

You’re going to get it wrong at some point. So do it ‘good enough to show someone’, get it wrong fast, get it wrong often, and keep doing that at every stage. It’s only at the end that you need to be a perfectionist. And then you’ll be spending your time perfecting something that’s right.

How to get it wrong less often

I don’t like to estimate on the sort of projects that I really like working on. But sometimes I have to quote, and I usually quote too low. I know I do, I try not to, but still I fall into the trap. Not any more.

There are very few people who can accurately estimate how much time or how much money it’s going to take to complete a software project. And there’s a well-known reason for that… the human brain is hard-wired to get it wrong, no matter the IQ.

Everyone has heard of, and maybe some have used, the quick-and-dirty method – Carefully cost everything out, then double your estimate. Multiply by a factor of 2.
And you’d be quite right to use the doubling method, but only if you are pushed into rough guessing without any thinking time – in the elevator, or on a phone call.

Going ahead with a project and finding that the costs blow out, that it limps on forever, then you run out of money, support, enthusiasm… that can kill your reputation as well as your confidence.

You want to be sure you get it right first time. Yes?
So you sit down to do a “realistic estimate”.

Now, there are only 2 reasons that you’d want to estimate the time or money that a project might consume – either you want it to go ahead, or you want to prove that it’s unwise to start at all.

If you successfully demonstrate that it’s a bad idea, or rather that the projected costs outweigh the projected benefits, then it ends quickly. Move on to the next one. End of story.


BUT – what if you actually want the project to go ahead?

The owner of the project wants the project to happen because the outcomes would be worthwhile. The contractor wants it to happen because it sounds interesting and worthwhile. They get their heads down and really look at the details of this worthwhile and fascinating project.

The more detailed your planning is, the worse your estimates are going to be.

Now we start encountering the human brain. It’s full of awesomely useful tools to deal with the world, predict outcomes, and get what it wants. And these mental tools have been finely honed over untold generations to work to our advantage. Along with their awesomeness come some sneaky little partners-in-crime called biases.


Optimism Bias causes us to focus only on the good things. (Bad things will not happen this time, because this is a great project. Besides, if we thought bad things were likely, we sure wouldn’t be doing this detailed estimate, now would we? Bad things messed us up a couple of times in the past, but now I am prepared)

Political Bias causes us to bend our perception because we desire the estimate to be optimistic. (If this estimate is accepted, then the project will go ahead. And if the project is successful, then I will personally benefit. Therefore it will be successful. I can taste the outcome and it is sweet.)

The owner of the project really wants the project to happen. She has visions of promotion and status for getting it done. She has a budget. She has heard stories of people doing much more than this, in a few short days. She is optimistic. If the estimate falls into her timeline and budget…

The person who is going to make this happen, also sees the personal benefit. It might be money, experience, accolades, or more projects and clients in future. If the estimate falls into the timeline and budget…

Focusing on the unique details of a project plan causes a person’s brain to decide that this plan is totally unique, nothing like the past failures, and in fact much better in so many respects. (I see no problems that are unforeseen, I see no unexpected costs. Therefor this is going to be a much easier project than we first thought… )


Easy fixed — we can adjust for our bias!

A bias cannot be undone by being aware of it. Biases are not random, and you’ll only be adjusting within your own (biased) frame of reference. Every expert is just as biased as everyone else. That’s a fact you cannot change. That’s a dead end.


So, how to get it wrong less often?

Step 1- Be Aware

If the project is going to take more than a day to complete, if you stand to gain by the estimate being acceptable, or if you have to draft a detailed plan in advance, then you’re in grave danger of underestimating.

Step 2 – Decide what “class” of project this is

By using a simple technique called Reference Class Forecasting, it’s possible to get a really useful estimate, even when there are lots of unknowns. And you’ll be more likely to bypass those pesky bias errors.

Your goal here is to gather a number of examples of similar projects from the past. Your “Reference Class” needs to be something like “iPhone apps with 10-15 interface screens”, or “training 10 new users”. It needs to be a tight fit – but it also needs to be broad enough to allow you to gather a solid 5-20 examples. They don’t need to be your personal projects, so you can Google away, or ask colleagues who make iPhone apps or train users.
Make sure to include examples that have failed, cost half as much as typical, or took twice as long as the others – in other words, be sure to include outliers, not just ones that fit your own hopes/expectations.

Step 3 – Find the median for your Reference Class

Arrange the results in time or money order, then find the middle ground.
Don’t calculate the average. We want the result that’s in the middle of the sorted list. That’s the one you want to use as your estimate.
If you absolutely need to avoid over-runs, then shift higher up your list.


The resulting answer will probably horrify you.

Maybe the estimate will be so high that the project is cancelled.
Good, you would have lost money/time on it.

Maybe your estimate will be higher than another contractor.
Good, let them lose money/time instead.

But it will be way more accurate than your carefully detailed estimate. Probably by a factor of 2.

Hofstadter’s Law:
“It always takes longer than you think, even when you take Hofstadter’s Law into account.”

The health-care play house

Here’s an awesome idea – build a fake hospital in a huge warehouse, then let companies and innovators bring in their prototypes, and test them in ‘real world’ scenarios. Everything from robots, software, databases, diagnostics, social and organisational strategies.

Kaiser Permanente’s Garfield Innovation Center,  in San Leandro, CA, has labs, operating room, and an ordinary home set up. Their aim is to “bridge the gap between idea and reality”. IT people can test new gadgets and systems in a realistic setting. People designing hospitals can experiment with ways to make them more humane and efficient.

Everyone gets to make mistakes fast, iterate, and re-test.


What clients thank me for

People thank me for understanding their business models, for seeing connections, for recognising problems, and for knowing how to approach solutions.

Apparently, I see the forest and the trees, in equal focus. I can suggest options, I ask difficult questions. I point out the ramifications of doing things this-way or that-way. I observe how the problem might parallel something similar in a different context. I point out the good, the bad, the ugly. I own their problems as if they were mine. Then I look at how we can collaborate to put together a workable solution.

Which is not to say that what I am is any better than being devoted to repairing shoes, or making pottery, or running a factory, or teaching people how to de-grease engines.

I just have an insatiable curiosity and a need to find out more about anything that crosses my path. Someone might mention stopping at a kasbah in Morocco. I end up researching what exactly a kasbah is, how it fits historically and culturally, and then of course (who wouldn’t), I calculate how much it would cost per month to live in one, to work remotely.

That’s pretty much how my brain works — I am always trying to understand what it is about the objects, and thoughts, and artefacts, that occupy the focused attention of other people. Why is it that there can be a magazine that specialises in underground parking in Italy? Or why is there a company that markets only things in the shape of a frog? What is it about pure mathematics that sends some people into (almost religious) raptures, and at times fervent arguments?

What do stand-up comedy, quantum physics, and cake decoration have in common? (I have no idea, but it might be interesting to find out)

On more commercial topics, I like to see the connections and differences between different industries – how an idea from the business publication industry can be useful when considering how to build an iPhone app for Venezuelans. How does Content Management for niche information brokers relate to management tools for sales teams? I took a course on Software Gamification to understand what motivates people to fill out forms within their own company.

This is such an everyday thing for me. So much part of me that I assume everyone else does it too. So, I find it surprising when people make comment. As a result of this mind-set, I have been labeled a “full-stack developer” – a generalist.
I have an Architecture degree. Because it seemed to me that architects were the “last of the great generalists”.
The designer’s mind set, and the true meaning of professional “agency” are the most powerful things I learned from architecture. That, and being exposed to engineering, contract law, building trades, surveying, negotiating, estimations, quality, aesthetics, planning, scheduling, government regulation, conflict resolution, colour, ergonomics — a rainbow of ways to look at the world.

Most of the work people do is now hyper-specialised – working within a deep and detailed silo of knowledge. They don’t have the luxury, or ability, or simply the language, to find out what’s going on elsewhere.

So, yes, people come to me with problems impossible to solve within their sphere of knowledge. I help them to clarify what they want to see happen.
I come up with solutions, and they say “Thanks, dude.”




What makes me Really Angry

Contentment. It really rubs me up the wrong way.

It seems to me than when a person is totally content with their life, then they have basically said “That’s enough knowledge for me. That’s enough improvement for one lifetime. Nothing more is required. Things cannot ever be better than they are right now.”
They might not be saying it, but I hear these words – “I will now stop trying.”

There are ten thousand ways that their life could be better, deeper, fuller, longer, interesting. They have just decided to settle for the world being “pretty much the way it is”. No thought of making an effort to improve anything. Not even mustering the effort to observe out loud how someone else could improve things.

Lack of curiosity. That’s the other thing that disturbs me.

I say disturbs, because I can’t exactly get angry with people who lack curiosity. I guess I put them in the same mental pigeonhole as people who are deaf in one ear, or lack bifocal vision, or are somewhere on the autism scale. They are perfectly nice people, and they get along fine.

I just don’t understand clearly what’s going on inside their heads – when you tell an incurious person about something, they say “that’s interesting” … and that’s all!  That’s where their interest stops. 

They don’t squeeze you for more details, nor immediately fire up Wikipedia or Google on their phone to find out more, to explore, to discover how this new piece of information fits into the wonderful jigsaw of human knowledge and experience. They just don’t see how this happily random snippet relates to them on any level. They never invest hours following stuff just for the joy of finding connections.

Perhaps they’ve just found contentment.