I remember a conversation I had with my dad several years ago. I was talking about the laser 3D sensing technology of the self-driving car exhibit I had recently seen. I was brimming with ideas for how this new technology could solve so many problems — using swarm intelligence to mitigate traffic, continuous ride sharing to decongest roads and street parking, etc.
After a few minutes of me rambling on, my dad paused and replied, “Well, what about all the bugs?”
“What do you mean?” I asked.
“You know, we have so many bugs in West Texas. A sensor on the road is bound to get all gummed up with bug guts.”
At the time I thought he was just being difficult, but looking back, I think my dad made a very important point. Even the most sophisticated sensor technology can become useless when a few bugs are thrown at it at 70mph. It’s important to be mindful of the role your technology will play in the real world — to step back and take a holistic view to better see challenges.
There’s no better place to see the unique challenges that come from a holistic view than in our Samsara Driver App. At Samsara, our technology is embedded in the industries that we serve. This is especially true for the Samsara Driver app, which serves as our all-in-one hub for fleet operations.
It’s important to be mindful of the role your technology will play in the real world — to step back and take a holistic view to better see challenges.
While our app serves a huge variety of industries including passenger transit, K-12, state & local governments, and field services, trucking is one of the largest industries we serve. The trucking industry is the backbone to the U.S. economy, employing 3.5M drivers and shipping 70% of our domestic freight. This means the drivers using our app need to be able to rely on it. It’s by understanding our app’s role within these industries that we can start to see the unique challenges our app must consider. Some of these challenges include:
Providing visibility in remote operating areas
Some apps support offline functionality to varying degrees but still expect a mostly consistent and reliable network in order to perform well. This isn’t the case for the Samsara Driver app. We expect our drivers to go great distances with spotty network connections or to change out trailers in the remote countryside. Our app needs to enable drivers to be productive even when they don’t have a network connection. It’s really awesome to help build the system that supports this.
Optimizing performance on non-premium devices The practicality of the trucking industry provides some interesting constraints that foster innovation and creativity. Often the devices our drivers use have low memory availability, throttled networks, minimal storage space and MDM (Mobile Device Management) restrictions. When developing we need to consider the capabilities of the mobile devices our app runs on.
Ensuring uptime during high growth As the number of drivers using our app grows, we need to develop for stability, reliability and availability. Any downtime can cause broad impact to fleets across the world that depend on our services, from logging driver hours and tracking deliveries to monitoring routes. Making sure we are able to iterate and move quickly while being minimally disruptive to our users is imperative.
Our drivers need to create and modify documents despite poor network connectivity.
Having a user-centric perspective is just one aspect of having a deep and varied knowledge of a product. It’s also important to think about the lifecycle of a feature and how your code fits into the larger system. With this in mind, here are a few practices I’ve found helpful when developing on mobile.
Choosing appropriate metrics and tracking them are critical aspects of the lifecycle of a feature. What is the developer’s relationship with the feature once it’s released? What is important to track, and what would be noise? How serious are the failure cases, and how best can they be monitored? Ask yourself these questions and equip yourself to respond. It’s a good idea for the team to have a frequented dashboard with a few of the most significant graphs, and individual engineers can monitor more specific metrics.
One of the most effective ways I’ve found to increase the reliability of my code is to make friends with QA (Quality Assurance). It’s so helpful to get the insight of an engineer whose full-time job is to consider the breadth of the product and the common paths of fragility.
At Samsara, engineers communicate their test and release plans with QA before the feature is merged. This fosters collaboration early in the process, allowing engineers to point out unique caveats to the feature and allowing QA to catch regressions quickly.
If you’re not testing on devices that reflect your user’s environment, you’re not close enough to the user experience. This could be considered an aspect of dog-fooding, or developers using their own product for real-world usage. This is something we do enthusiastically at Samsara. To attempt to mimic the actual customer experience as closely as possible, we have testing devices that reflect those used by the organizations we serve.
For example, some of our larger organizations have MDMs set up on driver devices that prohibit app installs, uninstalls, and updates. In order to understand how our app behaves in this environment, we have test devices that use these exact MDMs.
Functionality takes on a life of its own once it’s in the hands of users. It’s important for engineers to understand the limits and mechanisms underlying the code logic. What’s the complexity of the algorithm? What are the upper and lower bounds of data it can expect to process?
As Samsara scales to support more customers, some of which manage thousands of assets and drivers, we as engineers need to be able to answer the questions, “Can your feature support a hundred drivers? A thousand? Ten thousand?” We need to implement graceful solutions when these bounds are exceeded and have a deep understanding of where the limits lie.
If you understand your users, you can start to develop personas that represent a cluster of user behaviors and characteristics. For example, we could create a fictional driver persona, Bob, who represents a driver who uses the app for produce delivery. Bob drives 8-hour shifts on weekdays, in good connectivity, and makes as many as 20 stops a day. At each stop, Bob interacts with his customers, whom he sees weekly on his regular route, and relies heavily on our Documents feature to manage all the orders. On the other hand, we could create another driver persona, Sally, an over-the-road trucker who frequently drives across long stretches of American highway with poor connectivity. She relies heavily on our driving logs feature, frequently drives at night and stops only for legally mandated breaks. User personas can help us to quickly begin to distinguish patterns of user behaviors.
How many different user personas do you have? How varied are their app experiences? What are the most common paths each persona takes? Once you’ve answered these questions, it becomes easier to reduce friction on the most common user action sequences. Here at Samsara, we really invest in getting to know our customers. Our user research group visits customers on-site to ensure we understand what it’s like to walk in our customers’ shoes, and we encourage developers to visit customers as well.
At Samsara, we’re experiencing rapid growth on every front. We have more developers contributing to the mobile app, more teams specializing in various product verticals, more organizations and bigger organizations with greater drivers, vehicles, and trailers online than we’ve ever experienced. It’s important as we experience this growth to consider these practices to ensure we build sustainable products that give our customers the tools they want and need.
I think back now to that conversation I had with my dad and the lesson learned from his comment — how it’s important to consider your code outside of the bounds of its creation and in the hands of its user. It’s important to have an intimate relationship with the mindset of the user, the landscape of the code base, and the growth of the feature as more is demanded from it. And of course, keep your eyes out for bugs.
Swing by our page to check out our open engineering positions, or meet us at an upcoming event! At Samsara, we welcome all. All sizes, colors, cultures, sexes, beliefs, religions, ages, people. If you enjoy learning and building things in a highly collaborative environment, we’d love to hear from you
Thanks to Elisha Paul.