Boiling Oceans

When discussing architecture and design, a phrase that I’ve become increasingly critical of is, “Don’t boil the ocean.”

I see the phrase used:

• When [x] becomes infeasibile to execute.
• When [x] becomes too abstract.
• When [x] involves too many stakeholders.
• When [x] jeopardizes value proposition.
• When [x] seems to reach too far.
• When [x] starts to experience diminishing returns.
• When [x] takes simply too much time.

Where [x] is an activity in some form of forward looking capacity such as architecture or design, planning, etc.

But if someone says to you, “don’t boil the ocean,” does that mean you should compromise on your forward looking activity? I suggest not with a caveat. I say the cost of being directionally incorrect is too high. I say the cost of building out a weak foundation will spell disaster later on.

Think as big as possible, but solve as little as possible.

My advice on the matter is to plan to boil the ocean one cup at a time. To me, this means being directionally correct, building atop a strong foundation, but incrementally realizing the vision. Take an incremental approach by internalizing trunk development’s notion of application stragulation in [1].

This isn’t a new idea: the folks that build Firefox Quantum [2] wrote about their experience boiling the ocean (incrementally) when they described the creation of Stylo, “[a] culmination of a near-decade of R&D, a multiple-moonshot effort to build a better browser by building a better language.” Although their journey was long and reeked of second system’s syndrome, in the end, they succeeded by incrementally providing back value, all the while staying true to their vision.

This is the essense of boiling the ocean, one cup at a time.

\n