Consider a team of engineers building a feature API for Snapchat. Let’s call them Ovah’s team. They’re facing two big problems: how to build it, and how long would it take.

If they can’t figure out how to build it, the feature is dead already. If they take too long to build it, the feature is as good as dead: Instagram would copy it before they’ve built it.

This post contains 4 different perspectives to look at the two problems. As you read through the perspectives, notice the tension in the examples. Both problems are vastly different, and some perspectives are better for one problem, and worse for another problem.


The Outside View

To take the outside view, Ovah’s team compares this feature to other similar features they’ve built in the past. They built earlier features using Flask, and it took them 1 month to do it.

The outside view says that a good estimate for how long it would take is 1 month as well.

Further, the outside view says that a good estimate for how to build it is how you built it in the past: using Flask.1

The outside view looks for similar problems in different contexts. It’s a behaviour level model: you look at things only from the outside. How things change from the outside are hints to what’s important on the inside.

You’ll notice that figuring out how long it takes might do well with the outside view, but the API design decisions - not so much. What’s different between the two problems?

Taking the outside view on API design decisions is like building a truck using a car model. Just because it has 4 wheels and behaves the same as a car doesn’t mean it’s used for the same purposes.

On the flip side, not taking the outside view for figuring out how long it would take is a fallacy. Daniel Kahneman writes about the outside view in Thinking, Fast and Slow2:

“People who have information about an individual case rarely feel the need to know the statistics of the class to which the case belongs”

The Inside View

To take the inside view, Ovah’s team looks at the components of the problem. They look at the requirements for the feature, and come up with a good design tailored exactly for this use case. It’s unique. They decide to go with Django instead of Flask, since it gets them authentication and other nice things out of the box.

The team figures that with Django, most things are done for them already, so it should take about 2 weeks.

The inside view looks at specifics of the problem. It’s a gears level model: you understand how things tick. You figure out how each component would work.

Taking both, the inside and outside view is better than just taking one. It’s like going to the eye doctor, where they show you unreadable letters on a lit-up screen. They add one lens on your eyes, and you begin to distinguish o and e. Then they add a second lens, and now you can even tell the difference between h and n! They add a third spherical lens, and the dots become sharper - you can now even see the dots over the i’s as circles, not blobs. Each lens is a perspective that sharpens your view. It helps you realise that you’re looking at evan’s team, not ovah’s team: and then everything clicks.

In this case, using Django was a good decision. However, it took much longer than 2 weeks: unexpected things went wrong, and the team’s imagination was limited by how things can go right.

I think engineers are better at designing APIs than they are at figuring out how long it would take, which hints at them being better at taking the Inside View. This makes taking the Outside View even more important: if no one else is thinking like you, you have a sharp lens no one else has, which makes all the difference.

At the same time, you need to beware of Maslow’s Hammer: If you only take the Outside View on every problem, you’ll end up with a bad API design.

The Bird’s eye View

To take the bird’s eye view, Evan’s team looks at how this API should connect to other teams and clients. What are the other components involved? How can we best design things to work seamlessly with existing workflows?

The bird’s eye view looks at the problem as a part of a system, a part of other problems. This is different from the outside view, since it’s still the same problem in the same setting, but being looked at as an interface: how it connects to other things and other problems.

Amazon is a company that internalises the bird’s eye view: Every team talks via interfaces! Every other team is their customer. You can’t go to your friend and ask them to open a backdoor for internal calls: it needs to be part of an interface anyone in the company can call. This means, not just clients, but also their colleagues and friends face the pain when the interfaces are hard to use.

What would it mean to take the bird’s eye view for the second problem? Evan’s team looks at how long their dependent teams would take, and when customers would be most likely to upgrade. So, they decide to launch with the next filters release, using that as a guiding factor: if the feature won’t get done by this time, build a smaller feature.

The worm’s eye View - Genchi Genbutsu

Genchi Genbutsu means to “go and see”. Go to the problem, and see why it’s a problem.3

For Evan’s team, this means looking at the team dynamics, and figuring out if Evan or others are somehow holding the team back. It also means figuring out if they have the required expertise in the team, and if not, how can they build it.

Like how the bird’s eye view zooms out to the interface between other teams, the worm’s eye view zooms in to the interface between people in the team. It’s one layer deeper than the problem of designing the API: it’s about how the team will go about it. You’re looking at the problem as a single engineer among other engineers working on the same problem.

I’ve noticed that the Inside View, and the Bird’s eye view comes more naturally to people, while Genchi Genbutsu and the Outside View are rarer. The more uncertainty and unknown unknowns involved in a problem, the more important Genchi Genbutsu and the Outside View become.

The importance of taking these different perspectives shows up when you’re facing hard problems without an obvious solution: with the right combination of lenses, a blur turns into a sharp dot.

You can reply to this post on Twitter

Thanks to Anirudh and Hung for reading drafts of this.

  1. There’s a lot more decisions that go into API design, but for the sake of this example, I’ve reduced it to one word: Flask. ↩

  2. Affiliate link ↩

  3. Here’s a repository of genchi genbutsu stories I really like. ↩