DEV Community: Label Insight

The Pitfalls of Starting a Data Science Journey

Label Insight — Thu, 13 Aug 2020 22:01:46 +0000

When someone is not familiar with data science techniques, they look like magic, but they aren't! It might not seem like it at first, but how you approach a data science problem really isn't very different from how you approach a traditional engineering problem. And it might not be very far fetched for you to start a data science journey with your company.

But be warned: getting started with data science can be a slippery slope, with some pitfalls when it comes to pushing a proof of concept through to become a production-level model.

Starting out and treating data science differently

One of the first things we realized was that the project scope should be a huge concern when building a solution. When we were starting out, we often tried to make data science solutions that could shoot the moon. Quickly, we learned that this is NOT the way to do things. We ended up making things difficult for our data scientists, hard to debug, and truthfully the solutions were not very effective.

The problem was when we’d start planning a system for solving a complex problem, we’d fail to start from a modular level, similar to how we’d apply DRY or Single Responsibility software design patterns to a traditional engineering problem.

The result would be a vicious cycle, starting with a small amount of engineering work to serve the model and do some data manipulation, followed by a large model that tried to solve the entire complex problem. Ultimately, our solution would work great given a very specific input, but we’d encounter a use case where the model wasn’t effective, sending the data scientist back to the drawing board. After a couple of weeks, we’d have a new model solving for the specific use case, but less effective for the original one.

To illustrate, let's say we’re trying to predict the color of images, so we gather our data and start training, using a Convolutional Neural Net (CNN). But then, we realize we can also predict shape! We add that prediction and retrain the model.

This one little change potentially causes two problems:

If the shape prediction is struggling, we make a change to fix it, training both shape and color predictions since they are the same model. This can be the beginning of that game of whack-a-mole.
We increased the complexity of our model by up to 50%. Every prediction we add to our model adds a level of complexity to our solution, adversely impacting the speed and ease of working on our model.

Starting again with a new approach

At this point, we tried applying some trusty old software design patterns, ultimately breaking our solution into multiple models that could feed into each other (or not, if we chose), with each tailored to one piece of the problem. This did mean a little more engineering and data science work upfront but it was worth it.

Now, when we encounter an inefficient use case, our data scientist can take a couple of days to fix it, leaving the rest of the system still in place. This made updates like adding additional use cases simpler and less stressful, testing got easier, and things started to become reusable.

The importance of having the right data

You need data!!! Our company has a lot of data. We build solutions around consumer packaged goods, and thus, we have a lot of data on these products.

Having data and having the right data are very different—this is something we learned very painfully.

In our case, the data being captured for our existing solutions didn't quite match the format, nor the specificity of what was needed for the data science solutions that we wanted to build.

There are techniques to get around having a good amount of data, and most of them involve some sort of synthetic data generation. It’s important to note, however, that solutions built with synthetic data versus real-world data end up performing very differently as a result of the opinions inevitably built into the synthetic data. For these solutions, the variety of the real world can wreak havoc on the accuracy of a solution.

Nothing is a “silver bullet”—not even data science

Going back to our first comment:

When someone is not familiar with data science techniques, they look like magic

Kafka, GraphQL, Graph Databases, Serverless Computing. When someone first sees them, they look shiny and new and they think it will solve everything. This is never the case—no one particular solution is perfect. At the core, it comes down to statistics and probability, and data science is really good at solving for solutions that are probabilistic at their core as well.

Take something like Optical Character Recognition (OCR), a widely accepted technique to pull text off of an image. This idea came around in the 1920s. It has since seen almost 100 years of iteration, with the first real solution coming around in the 1970s and more widespread cloud-based solutions coming around in the late 1990s.

Even with all that iteration, there are still very common issues. For example, depending on training data, OCR struggles with recognizing “g” versus “9” and distinguishing “1”, “i”, and “l”. It can also struggle with colors or fonts. All data science solutions are going to have their limitations, and this has to be understood and accounted for when developing a solution!

Managing Expectations

It’s very easy to get excited about the potential of data science applications, and this can be especially true outside of the engineering department. When someone who interacts with customers regularly, whether they are from a sales or customer success team, hears about a potential data science solution, they can get excited and this can lead to pressure to deliver. But if that person is not involved in planning, developing, training, and maintaining the solution, this pressure can be stressful, leading to rushed timelines and ultimately to poor implementations.

People can be skeptical about what can really be done, especially if these problems have been difficult to solve in the past, so on the other end of the spectrum, you could have to build hype and excitement if it’s lacking.

We failed at managing expectations in the beginning but have learned how to do this better over time, and data science is now at the forefront of some of our initiatives and trusted by our entire organization. We accomplished this by keeping the scope of our solutions small and being deliberate and disciplined about metrics and sharing learnings.

Data science truthfully builds hype for itself if the solutions work. As data science evolves in the organization, it becomes more trusted and the space for building solutions.

Final Thoughts

Data science is awesome. It makes some difficult things very easy, is fun to build, and the results can be downright awe-inspiring. There are tons of pitfalls as someone begins introducing data science into their organization. The pitfalls and tribulations are going to be different for every organization, but patience is key and visibility and communication will make the entire journey easier.

Serverless-Side Rendering With Lambda at Edge

Label Insight — Thu, 02 Jul 2020 21:11:41 +0000

by Joe Duran

A flagship offering of Label Insight’s tech services is our LabelSync product. LabelSync customers expect their SmartLabel landing pages to be performant, globally available, and resilient to failure. We recently upgraded the infrastructure that powers these pages to leverage React and AWS Lambda@Edge, in order to provide our users with a dynamic web application that scales automatically and makes our data more secure. Read on to learn more about serverless computing at the edge!

State of Play

Prior to upgrading our infrastructure, our SmartLabel landing pages used a traditional client-side web application to fetch and render data using Angular.js 1.x. Requests to our SmartLabel domains were handled by a CloudFront distribution and the code for the templates was stored in S3. This application model provided a high-quality experience for our customers but presented a number of challenges for us as an engineering team.

Maintaining Angular 1

While Angular.js was a suitable choice for client development at the time of the SmartLabel application’s initial construction, by 2020 our company’s front end infrastructure favored React. We cherished the opportunity to burn down one of our last outstanding Angular applications so that our SmartLabel landing pages could inherit the benefits of our streamlined, modernized React development practices.

Public API Endpoint

Since SmartLabel pages were publicly available on a number of domains, any API calls they made on the client had to be similarly public. This meant at least one SmartLabel API endpoint had to be unauthenticated. We long suspected the endpoint had been scraped by competitors and hoped that our new solution would allow us to sunset it.

JavaScript BundlePhobia

SmartLabel landing pages are simple, mostly-static websites that require little user interaction beyond sub-tab navigation. Unfortunately, our Angular 1 implementation required every user to download a hefty JavaScript bundle, without which the template could not render. We didn’t code split either, which meant users were often downloading code they didn’t need. We wanted our new version of SmartLabel pages to work with as little client-side JavaScript as possible.

Our Solve

Our 2.0 application leverages Lambda@Edge, an AWS offering that allows developers to run custom code off of CloudFront events. In our case, when a user makes a request to a SmartLabel page, a lambda function fires that fetches the necessary data and renders the entire page as static content. Let’s take a look at how this model solves the three problems outlined above.

React Please!

The new SmartLabel template is a React component. We already have a slew of best practices for developing with React, and find it a breeze to test and deploy code using tools like Jest and Storybook. We can leverage our shared library of components to ensure that our users’ experience is uniform across our software suite. We also have the added benefit of not having to context-switch between Angular and React when developing features for our LabelSync product.

No Client-Side API Calls

Now that the SmartLabel template is rendered in a Lambda function, there is no need for a public API endpoint. The necessary data for hydration is stored as a global on the window object and parsed when the JavaScript bundle eventually downloads. Users experience faster load times since the first render on the client contains the complete template.

No Bundle Required

Our new SmartLabel experience degrades gracefully in low-bandwidth situations. In fact, the landing pages work fine without any JavaScript at all, using traditional <a> tags for tab navigation. This means our customers can these landing pages even in grocery stores and other retail environments where internet speeds may not be ideal, and when the bandwidth is sufficient, while knowing they’ll get a modern, snappy web app experience.

Lambda@Edge solves all three problems we identified with our old infrastructure, but in fact it does more than that. L@E auto-scales with our app’s traffic, so we don’t have to think about servers. CloudFront caches the results of the lambda so subsequent requests to the same page will not result in duplicative lambda efforts. Our AWS costs for the entire application are on the order of pennies.

Like what you see? Follow us at our company GitHub page or dev.to for more updates!

My Journey Transitioning From Individual Contributor To Engineering Lead

Label Insight — Tue, 19 May 2020 21:07:36 +0000

by Blair Motchan

I’m not an expert lead developer and I’m not writing as an authority. Rather, I am writing about my experiences, how I approach my new responsibilities, and how I try to improve myself and teammates as an engineering lead.

The roles and responsibilities of a “lead developer” (and the title’s variants) have always been a bit vague to me. Not to mention that every company and department treats the position differently. So, when I became an “engineering lead” I was a bit unsure of what my next steps would be.

Fortunately, I have some great mentors at Label Insight, and our department has adopted the philosophies found in The Manager’s Path, Camille Fournier - O’Reilly Media, Inc, USA - 2017. Both have shaped how I’ve decided to lead, and I’ve outlined some strategies, thoughts, and advice below.

Transitioning away from being an individual contributor

According to Fournier, “Your highest priority as a tech lead is taking a wide view of the work so that you can keep the project moving.” — The Manager's Path, 32. Transitioning away from an individual contributor was one of the hardest steps for me because I had to “let go” of development as I formerly knew it. Instead of being the person who could handle and manage any project or task, I have stepped back and now equip my teammates to do the same.

“You should continue writing code, but not too much.” — The Manager’s Path, 32.

I now spend most of my time gathering better requirements, facilitating team discussions, creating architectural diagrams, answering questions, and working more closely with project managers and stakeholders. I still work on smaller, less critical stories, though. The Manager’s Path recommends still staying highly technical at this stage so that you can understand, point out, and prioritize the team’s pain points and bottlenecks, and also keep the respect of other engineers. — The Manager’s Path, 77.

Mentoring, coaching, and managing

My approach involves helping my teammates work and excel in areas that they are interested in that also have a high value to the company. I benefit from this because I get to know my teammates and company better. My teammates benefit because they take a closer look at what motivates them. Finally, the company and department benefit because people are working on areas they are the most interested in.

Know your environment

“The important thing for you to start doing now that you’re in management is to learn how the game is played at your company. Every company has its own variation of the promotion process, and you’re probably in this role because you survived it.” — The Manager’s Path, 69.

Merit is determined differently at every company and department, and every company values certain types of work more than others. Potentially most importantly, every company has different processes and procedures for getting raises and promotions. Having a good grasp on all these areas will help you identify how to best help the engineers that work with you.

Understand your teammates

Knowing how to be successful at a company is not enough when you are leading others or are a lead developer. I try to understand how the engineers I work with are motivated so that I can help them be as successful as possible. Engineers want to do a great job and write great software but translating that desire into motivation is not always easy.

While information from personality tests is important, I prefer to just get to know people very well through regular one-on-one meetings and working closely with them. Patterns will emerge that will indicate what motivates them. As Fournier put it, “... get to know the person reporting to you as a human being.” — The Manager’s Path, 56.

Lead by example

I apply “The Golden Rule” to my personal and professional life: I try to be the teammate for others that I’d want for myself; to me, this is the essence of “leading by example.” As a leader, people will look at you as a role model and will either adopt your behaviors or believe that the way you act is accepted behavior at your company and department.

When leading by example it is imperative to keep a positive attitude. It only takes one person with the right attitude to make a difference and begin solving a problem and then others will follow suit. Similarly, it’s important to celebrate achievements and accomplishments because the positives will overshadow the negatives. According to Fournier, “the trick is not to focus on what’s broken, but to identify existing strengths and cultivate them.” — The Manager’s Path, 119.

“Play to your strengths, admit your weaknesses, try to improve, and be honest.”

If you find yourself in a similar position, I hope some of my thoughts help you to be a better leader or lead developer. Earlier in my career I did not know what to look for in a supervisor or manager, and I now try to provide the leadership that I realize I was missing. My final piece of advice is to understand your own strengths and weaknesses as a person in order to be a successful lead engineer. Play to your strengths, admit your weaknesses, try to improve, and be honest.