How a Good Idea becomes a Good Product at Ibotta

The Story of Implementing a Campaign Inspection Service

Jesse Spevack
Building Ibotta
5 min readNov 30, 2017

--

‘A good idea can come from anywhere’ is one of the Ibotta core values and one of the reasons working as an engineer at one of the most vibrant startups in Denver, Colorado is so rewarding. This month, my team was able to turn a good idea into a campaign inspection service that will save our company money and improve the experience of our clients.

In October, I ran a check on the data integrity of our system’s campaign_billing model, which stores information on how we bill our clients for running cash back offers in the Ibotta app. I wanted to check that the fee structure of each campaign_billing was in line with the actual business cases it is intended to model.

Our manual data entry process for setting up our product offerings can be prone to error. I wrote a script to run a couple of quality control checks to stop potential errors from manifesting themselves downstream.

This initial script had almost no organization or abstraction. Imagine that our campaign creation process is like a factory that manufactures a product. Think of a single quality assurance worker in that factory who has no notion of the purpose of the final product being manufactured. Rather, the worker has a long checklist that can be used to judge each finished product. The worker randomly selects a finished good from the disorganized pile at his feet and runs through the entire checklist. If all of the checks pass, the product is shipped, if not it is returned to the factory for improvement. There is no efficiency gained through delegating specialized tasks to different workers with particular skillsets. That is more or less how I first conceived of this quality control process.

On bringing the results to my team, Maciek Swiech, the Adaptive Content Team Lead, recommended that I automate the the script so that we can flag campaign_billing issues for review as they are created. My team pushed me to fully productize the process of reviewing campaign_billings and the solution we landed on embodies the culture of creativity and teamwork for me at Ibotta.

Now imagine in your mind’s eye the same factory as before, but with a highly efficient quality assurance process. Instead of a random pile of finished goods, we have a hopper of items that are most likely to contain business-impacting defects. The hopper places each item at the start of a conveyor belt where instead of one worker, several quality assurance workers stand waiting at various stations ready to check each good for a particular defect.

In our implementation of the campaign inspection service, the finished goods are recently updatedcampaign_billings. The quality assurance workers are Inspector objects. Failed checks are recorded as Flag objects. These flags are aggregated into a Report object that is emailed as a csv summary daily to the appropriate teammates.

At Ibotta there is no shortage of talented engineers. In fact, one of the best parts of working on such a strong team is that I get to review, maintain, and adapt code written by engineers who have been writing code for many years. Like many pursuits, one of the best ways to improve one’s coding skill is to work alongside software developers with more skill and experience than oneself. I credit a significant portion of my second approach to thinking about code written by Aleksandr Furmanov, an experienced software veteran I have gotten to work closely with ever since joining Ibotta.

The code for this project is my most substantial pull request to date since joining the Ibotta team this past March. There were 72 individual commits spanning 32 different files in our Rails application. There were 87 comments from 6 different engineers. Some comments were complimentary.

Other comments were constructive in nature. Or intended to catch careless mistakes.

Still others were challenging pushing the team to land on the best possible solution.

What these discussions should make clear is that at Ibotta, and particularly the Engineering team, we value teamwork — another one of Ibotta’s core values.

In addition to the written feedback and discussion in github, my team also had an in person code review which led to a more encapsulated solution. Before the code review, the conveyor belt moving campaign_billings through the quality control process had branches that would divert campaign_billings to the appropriate inspection. My team pointed out that moving campaign_billings and deciding where they should be moved are two different tasks. As a result we kept the conveyor belt functionality in the CampaignInspectionService but moved the decision making into a separate class we called an InspectionManager. The InspectionManager looks at each campaign_billing as it makes its way down the conveyor belt and tells a specific Inspector to perform a quality assurance check. This type of encapsulation makes it easier to change and update code because single responsibility code is simpler for others to understand.

I am proud to work at a company that embodies its core values, like a good idea can come from anywhere. The CampaignInspectionService is not a top down mandate; it is a bottom up discovery in terms of improving internal processes and it is already saving the company money. As a team, we worked together to land on an extensible solution. Managers trust engineers to prioritize work that will add the most value to the company. I suspect that Ibotta’s continued success is in large part due to the company’s value system, which breeds success and makes working here a lot of fun.

--

--