The Crucial Lesson About System Design I Learned On a Sail Boat
I help people use technology to work efficiently. I analyze the way people work, find broken processes and/or systems, and help find a solution using the most current technologies.
I am not a strict academic. I am always looking for inspiration in odd places.
Most people wouldn’t think that Northern New Jersey is a great sailing destination. But a few wonderful little lakes in the Garden state perfect for sailing. I was lucky enough to grow up within walking distance of such a lake. This lake had a no-motorboat policy, and it was perfect for a pre-teen to mess about in small sailboats and canoes.
My family had two sailboats in succession. The first was a Styrofoam bathtub with a single sail that my aunt and uncle gave us when they redeemed some cigarette carton coupons. It was the 70s and we had the “Kool” sailboat. I was too young to understand, but this was an incredibly successful marketing campaign by the cigarette company. Have a look at the article here: https://medium.com/the-end-of-the-road/a-kool-cigarette-sailboat-9545a6f3c6f3
Aside from being painfully slow, the Kool boat had the annoying habit of filling with water as you sailed. It couldn’t sink because it was made of Styrofoam. But you ended up sitting around in a wet bathing suit all afternoon regardless of how much you bailed.
After several summers we retired the Kool boat upgraded to a secondhand fiberglass skiff called a minifish. This was a smaller, slower version of the AMF sunfish. Every day the weather was decent I would walk barefoot down to the dock carrying the sail, rudder and center board and spent the afternoon exploring the lake.
The minifish didn’t have the bathwater problem that the Kool boat had. You sat on the fiberglass deck and put your feet in a little indent while you balanced the boat with your weight. There was even a strap to loop your foot through when you needed to lean way out to counter a stiff breeze. Great fun.
Years later I learned to sail larger boats in New York Harbor. These boats had a cockpit, an area toward the back of the boat where the crew would sit, control the sails, steer, and generally enjoy themselves. This was a much more comfortable, and dry version of sailing.
But occasionally water would get in the substantial cockpit, especially when sailing on the ocean. I was a crew member on a sailboat from Bermuda to Long Island following the Newport Bermuda race one year. Passing through the gulf stream we encountered a storm that brought gusts up to 40 MPH. Waves were continuously dousing us as we pounded along.
That’s when I observed the miracle of design that is the self-bailing cockpit. It sounds complicated but it’s genius in its simplicity. With a large sailboat, the deck of the cockpit is above the waterline. In the back of the cockpit there is an opening that empties into the ocean. So, if any water gets into the cockpit, gravity empties it out for you. Incredibly simple.
What do I take from this?
1) Anticipate failure. Water is going to get in the cockpit. It must be removed.
2) Strive for simplicity. No pumps to fail, no moving parts.
3) Make it fail safe. There’s no need for an operator or alerting mechanism.
These are key ideas for software development. When you write a code module, you must be clear about what you are trying to accomplish. Good code anticipates, traps, and handles errors. This is basic, but people still forget. Most modern programming languages and development environments are good about telling the programmer when he/she has made a mistake. There are also good programs to check your code for these problems.
But the self-bailing concept is also useful when you think about business processes in general. For example. If you are developing an enterprise search environment, you are designing to provide people with good search results. When someone searches for a term and the system gives a good response quickly then your cockpit is dry.
But what happens when this does not happen? How can you define your self-bailing cockpit? How do you design a system that will recognize that your search results were inaccurate and then make corrections to get the correct results returned and prevent this in the future?
Some things you might consider:
- When the search results returned, was anything clicked on then rejected?
- When the search results returned, was another search run without clicking on anything?
- Did the searcher scroll down through multiple search pages?
- Did anyone else for the search term? What, if anything, did they choose from the search results?
Modern Machine learning algorithms help with all the above and help to get closer to our world of dry cockpits. Google search uses these techniques for constantly improving search results. Even the enterprise search embedded within Microsoft’s SharePoint product applies these self-refining techniques.
When we talk about Knowledge Management, we aim to get the right information to the right people at the right time. Search is great when someone recognizes when they need to seek information. Our searcher makes a proactive choice to search and evaluate results.
What if we could get the right information to the right person even when they didn’t know that they needed it? What if we could nudge or remind people that there is something that they should know that would make them work better.
We’re starting to see this in Gmail. Reply to an email, and potential responses magically appear. Begin a sentence, and Gmail will try and complete your thought as you are writing. Gmail can even remind you when to follow up or include an attachment referenced in your email. In all these examples, you don’t need to think, Gmail is helping.
So where do you need self-bailing cockpit’s in your organization? In what ways are you sitting around in a wet bathing suit? When water is coming over the side rails are you bailing like crazy? Or are you confident that you have nothing to worry about?
