Summary
In his weblog, James Gosling writes about how to "boil oceans," i.e., do something that would be impossibly difficult to do all at once. He warns against confusing a big vision with a to-do list, and instead suggests taking small steps today that move you toward the big goals.
Advertisement
In Boiling Oceans, James Gosling gives advice on how to implement a big vision. He says that at Sun, they refer to grand visions as boiling oceans, to emphasize that it would be unrealistic to try and accomplish the vision all at once:
At Sun we use the term "boiling oceans" to refer to trying to do something impossibly hard all at once.
Gosling's first suggestion is to make sure the vision itself is not bigger than needed:
[Boiling oceans] is an especially silly thing to do if all you really want is a kettle of hot water for tea. Engineering projects too often fall into the trap of over-generalizing, trying to solve problems that folks might concievably have, building things so large and elaborate on day 1 that they never get off the ground.
If you're sure you really want the big vision, though, Gosling reminds that:
A journey of a thousand miles begins with a single step.
He suggests that today you take one step, tomorrow another, and so on, towards the goal, and mentions that over time, as you take more steps, the goal will likely shift and adjust.
One of the big sources of the problem is confusing a vision with a to-do list. Implicit in taking the first step in a journey of a thousand miles is that you have to have some clue about where you're going. That's the role of a vision for a project. It's seductive to take the vision and turn it into a to-do list. But grand visions lead to insane to-do lists. The art of breaking them down into manageable steps can be a tough one.
Visions are notoriously slippery things. Your vision of a good place to go, of the right target for a project, is heavily dependent on the time and place where you are standing and looking out. With every step on a journey of a thousand miles you see things from a slightly different vantage point. Your vision adjusts. Your goal shifts. For me, that is one of the most exciting aspects of a project: I start out with an intent, with a vision of where I hope to end up, but the true destination unfolds in fascinating and surprising ways.
Often the hard part, as Gosling notes, is figuring out how to break down the grand vision into smaller steps. How do you break down big plans into manageable steps? Do you have any other advice for how to accomplish big goals in projects?
> <p> > Often the hard part, as Gosling notes, is figuring out how > to break down the grand vision into smaller steps. How do > you break down big plans into manageable steps? Do you > have any other advice for how to accomplish big goals in > projects? > </p>
I can suggest what worked for Terracotta: when attempting to cluster at the JVM level we noticed the previous attempts started with a fully-clustered heap implementation. We instead took a different approach:
1. prototype. Synthesize a use case and implement just enough to make that use case work 2. Find customers and DO NOT just cheat and synthesize another use case. Take the prototype and try to extend it to meet the real use cases. refactor. refactor. refactor. 3. Our version of "don't boil the ocean" was to decide to cluster the parts of heap that a developer specificies (via configuration file naming of classes, fields, locks, etc.) as opposed to clustering the entire JVM. I wonder if "configuration driven / declarative / AOP" is a rule or just worked in our case.
All told, we were able to get to market in just over a year with something that works for a reasonable set of use cases. Furthermore, we know which use cases it will not work for without blindly trying and wasting people's time.
Previous Topic
