Failing safely

In yesterday’s email, I pontificated about the challenges and potential payoffs presented when taking on complex UI engineering work like that demonstrated in this article about the Google Photos web app.

I find this case study fascinating for a number of reasons, so I’m going to indulge in some more pontification today.

The team’s ambitious vision for the product involved trying to satisfy multiple goals:

1. Be able to jump to any part of a huge photo library
2. Fill the width of the browser and preserve the aspect ratio of each photo
3. 60fps scrolling
4. Instantaneous feel

Imagine for a minute that you’ve been hired as lead UI engineer on this project. You’d be forgiven for running away somewhere for a bit of a cry and some alone time once you’d seen that list of requirements.

Believe me, this is a good sign, because it means you understand the constraints of the medium, platform and the diverse capabilities of users’ devices.

For me, once I’d got the initial shock out of my system, my problem-solving and reasoning systems would kick in, resulting in a rapid-fire set of thoughts aimed at reducing the size of this challenge.

My thoughts would likely include, in no particular order:

1. This will never work.
2. We could maybe achieve 2-3 of these at one time, but not all of them.
3. Achieving all of these will require some genuine abuse of the web platform and some disgusting hacks that will make me feel ashamed, assuming they’re even possible.
4. Maybe we could do all of this in WebGL? Or canvas? Or using that rendering library that got millions in funding and then disappeared? What was it called?
5. Assuming performance is the most important feature, can we treat number 2. as a nice-to-have and quietly ditch it later? Would that even make it easier?
6. What about that career change I was considering?
7. I need to go away and read up on scrolling and rendering performance.
8. We’re going to need to make the case for lots of time experimenting to get anywhere close.

etc.

The very worst response to facing these requirements is to promise that they will be achieved.

The second worst response is to provide a time-based estimate of how long it will take to achieve it.

The article is interesting for the reason that the web platform, browsers and JavaScript view libraries don’t provide ready-made capabilities to achieve what it describes out of the box. So the team had to be extremely creative and experimental in their approach. That doesn’t come cheaply or easily.

When you’re embarking on something that is not a solved problem and doesn’t have clear patterns of execution that are well documented, you’re taking on a lot of risk.

And the best way to mitigate risk like this is to experiment progressively. Treat it as team learning exercise. Identify the heart of the challenge - the riskiest aspect - and go at it full on, until you have a clear understanding of its shape and nature. Then move outwards to tackle other aspects and see how doing so impacts other goals.

Are some of the goals mutually exclusive? Is solving one far more costly than others? How far are you stretching the capabilities of the platform? How will this impact real users?

Then you can start discussing the pros and cons of proceeding, for project risk, for upside to users, for maintenance costs, and so on.

Ultimately, you have to remember that the article is likely to be an example of survivor and hindsight biases. The team successfully achieved their ambitious goals, and so decided to write about the work they did, after they did it. The same is far less likely to happen for similarly ambitious but unsuccessful projects.

We can learn a huge amount by taking on difficult work like this, because it stretches us. But we can only do so in a safe space where a successful outcome includes outright failure.

All the best,

– Jim