Explore vs. Exploit as an Architectural Choice

Karl L Hughes
May 15, 2017 · 3 min read

I’ve been reading (or rather listening to) Algorithms to Live By, which is about how we subconsciously use or misuse various computer science algorithms in our daily lives. Most recently I finished the section on Explore vs. Exploit, also known as the multi-armed bandit problems.

What do “Explore” and “Exploit” mean?

To “explore” would mean that we make the decision to try something new. For instance a restaurant we have never been to or a software framework we haven’t tried before. To “exploit” means that we take advantage of something we’ve already tried and had success with before.

People tend to explore more when they perceive there to be a long time before they will be “finished” and exploit more when they are approaching the end of their timeline. For example, we’re more likely to try a new restaurant when we first move to a new city than right before we move away from one. This is part of the reason older people tend to winnow down their friends and go to the same restaurant every week and by contrast younger people tend to seek out new relationships and try new places.

Software engineers are explorers and exploiters

We make this kind of decision all the time in software engineering. For example, if you were asked to build a new web application would you use a framework you already knew or try something on the cutting edge? When refactoring some code, would you try to only use patterns already used in the library or would you explore new design patterns?

I can think of dozens of choices like this that I’ve made in the past few months, and while some are pretty minor, many have a huge impact on how long projects take and how easy or hard they are to maintain.

Which option is “right”?

I’ve also been thinking a lot lately about whether or not exploration is important for project architects, and if so, how important it is. After all, most mature frameworks and patterns have documented use cases for almost any type of project. Why should we try out new frameworks when all the problems are solved by existing ones? Isn’t this just an unnecessary risk?

Some people would say so, but then others would disagree. How can we retain and hire good people if we aren’t taking advantage of the latest technology? What if the new tech is faster/easier/better?

There’s not a right answer to the question, but knowing how and why humans make explore and exploit decisions can help frame these questions.

Young engineers explore; senior ones exploit

If your early-career engineers are constantly pushing for exploring, that’s probably normal. Similarly, if your senior engineers are usually advocating the exploit strategy, it probably comes from a place of security in the known advantages of a well-worn strategy.

I’ve realized that as I grow older (and more experienced) I do a lot more exploiting. I’m still pretty explorative, but not everything is new anymore. I want some things to be familiar; I crave that security.

Karl L Hughes

Written by

Technology team builder, software engineer, and startup enthusiast. CTO at @GraideNetwork and helping technology speakers succeed at @cfp_land.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade