How have learning cycles helped a Logic PD engineering manager avoid figurative shipwrecks in the product development process -- and find actual shipwrecks in Lake Superior?
Development of complex systems is inherently challenging. A common way to manage this process is to create learning cycles, with each cycle concluding upon reaching specific short-term goals. Managers like learning cycles because they provide a greater number of concrete project check points to gauge progress. Teams like learning cycles because they provide a sense of progress towards the goal and an opportunity to recover from short-term set-backs.
Just using the phrase “learning cycle” acknowledges that product development is the process of creating new information and encourages innovation. A practical, real-world example of how learning cycles are applied should help show how useful this approach can truly be.
The challenges of shipwreck hunting
I occasionally join my dad on his adventures hunting shipwrecks in the frigid waters of Lake Superior, where he has located the final resting place of more than a dozen shipwrecks. Underwater exploration requires equipment that can withstand extreme environments, which usually commands a price that is unaffordable to most hobbyists. Our solution was to build our own equipment. And we’ve found success in our efforts, having once located six shipwrecks in a two-year span. Our homegrown side scan sonar system, developed over 10 years of experimentation and improved image output, played a significant role in that success.
Transducer (towfish) of the homegrown side scan sonar.
These developments have allowed my dad to more efficiently advance the goal of his shipwreck hunting group, which is simply to find lost ships and tell their stories, becoming part of their story in the process. Photographs and video offer the most engaging way to tell the story. Finding a better way to capture those iconic shipwreck photographs and videos is the challenge my dad has spent 40-plus years pursuing and the impetus for my recommendation to add a thruster to their underwater camera.
Several obstacles exist in the underwater environment that could damage or even destroy a remotely operated vehicle (ROV). This ever-present risk has always led my father to forego the investment in motorization. He has only ever used drop-down cameras. With much practice, he has perfected the art of drift filming, a process much like painting a picture by standing on a chair, dipping the end of a long string into a paint can and dragging the string across a piece of paper sitting on the floor below.
Improving outcomes by incorporating learning cycles
Eventually, the process results in a photo mosaic of most of a wreck site, but it takes a very long time and several long, slow drifts on the surface above where shipwrecks lie to get a somewhat complete picture of the wreck below. And because drift filming uses a static camera trolling over the top of a wreck in a straight line, it’s frustrating to see something interesting at the very edge of the screen and not be able to turn the camera to get a better look.
To overcome these frustrations, we’ve started building an underwater thruster that attaches to the tail fin of the drop-camera so we can turn the camera side-to-side while it drifts over a wreck.
So how does this story relate to the application of learning cycles? Our long-term goal is to build an ROV that can be launched by hand from a small boat and provide well-lit scenes of the underwater wreckage. Previous learning cycles have resulted in several generations of working drop-cameras that have solved the challenge of properly lighting the underwater environment. Our recent challenge was to define learning cycles that move the project from where we are toward the final goal with an intermediate milestone product that we can start using this year.
Constructing effective learning cycles
While it is generally desirable to reuse elements from one learning cycle in the next, some planned rework is acceptable. It’s more important to remember that the goal of each learning cycle should be to mitigate a specific risk or demonstrate a specific functionality. Some learning cycles may result in dead ends that motivate a wholesale change to the system architecture, but such discoveries should not be considered failure if they occur early in a project when the cost of change is relatively low. Just consider the alternative of not performing the learning cycle and making the same discovery at the time of system integration.
With experience, the areas requiring a learning cycle become obvious. Anything new to you (or your company) is a strong candidate for a learning cycle. It doesn’t matter if others have completed a similar project hundreds of times before - the first time you try something new carries with it a greater chance you could make a mistake. Additionally, it is generally wise to test new components under conditions that closely match your application before making their selection final.
Learning cycles and Logic PD
We routinely employ learning cycles in my work at Logic PD. Logic PD has accelerated our customers’ learning cycles by providing thumb-sized system-on-modules (SOMs) that integrate the core processor and standard system components such as DDR and Flash memory, display controller including touch-screen, and wired and wireless interfaces including Ethernet, USB, WiFi and Bluetooth. In some cases, Logic PD SOM’s provide more processing horsepower than is needed for the application.
In these cases, we’ll select a suitable low-cost module or development board to create prototype hardware that serves as proof-of-concept and allows our software engineers to begin working with hardware earlier in a project. When these early prototypes are combined with specific goals and development milestones, those elements comprise to form effective learning cycle.
Engineering Manager and Systems Lead