Alice is a startup in New York City that helps hospitality, retail, and healthcare employees get an extra week of pay, for free. Employees connect their credit and debit cards, Employers connect their payroll systems, and Alice automates pre-tax benefits—no open-enrollment, no saving receipts, no use-it-or-lose-it—just extra money in paychecks. Because Alice handles sensitive data, they place a high premium on security and maintain HIPAA, SOC II, and PCI compliance with a lean Engineering team.
Backlogged Upgrades
Luke Rodgers is a Senior Engineer at Alice and has been there for 6 years. For the majority of Luke’s time at the company, Alice aspired to keep Rails and other core application dependencies up to date, but this work continued to slip on the backlog. There were several reasons these upgrades kept slipping:
- Poor Visibility: The Rails upgrade was perceived to be a nebulous and massive project. Without clear scope and visibility into future incompatibilities caused by the Rails upgrade, it was challenging to determine where to start or how to progress. According to Luke, “A Rails upgrade can feel like you’re heading into a jungle.”
- Staffing Issues: This ambiguity informed a belief that only the most senior engineers on the team could be involved in the project. Allocating these resources to a dependency upgrade of unknown complexity would come at a huge cost to the company. “Luke’s focus is precious to us,” said Avi Karnani, Alice’s CEO.
- Cost Implications: There were very real opportunity costs to assigning senior engineers like Luke to the Rails upgrade project, but there was also a very real and direct cost to alternatives: “A vendor had given us a quote for $200,000 to upgrade Rails, which seemed like a lot of money. Maybe that even contributed to our sense that this is just some giant, untamable beast.”
These challenges combined to push the Rails upgrade further down the priority list, leaving it lingering in the backlog for years.
Upgrade Debt's Tipping Point
Over time, the issues caused by the lingering Rails upgrade accelerated and started to cascade into other areas of the business:
- Security / Compliance: The first was Alice’s security and compliance posture. As new security patches came out, Luke and his team were unable to easily patch vulnerable dependencies because they were blocked by major, complex upgrades like Rails. “We would need to monkey patch a gem because there was a security patch that we couldn’t get to.” Although this fixed the problem in the short term, it added considerable maintenance debt to the codebase and increased the overall time to remediate.
- Planning Costs: The amount of work associated with dependency upgrades increases at an accelerating rate over time because a codebase's dependencies are always shifting. Said another way, dependency upgrades are a moving target. For the team at Alice, attempts to manually research the Rails upgrade “got stale over time because we actually removed this other gem or these gems got upgraded for some other reason. So it's this shifting landscape that every time someone picked it up again, they'd have to sort of start fresh," said Luke.
- Employer Brand: Great engineers generally want to work on the latest versions of tools. As Luke pointed out, this is also a useful signal to potential hires that a company “isn’t just a feature factory. That the executives understand the importance of paying down tech debt.”
Discovering Infield
Luke's introduction to Infield came via a post on Hacker News.The post highlighted Infield's Upgrade Path feature, which seemed to remove two major points of friction for Alice getting the Rails upgrade completed. The first was that Infield gave the team a clear, step-by-step plan for the upgrade, potentially saving weeks of work and significant costs. The second was that the plan updated dynamically, allowing different team members of varying seniority levels to “snap into maintenance mode without having to reload a bunch of context.”
Over the course of the following 4 weeks, Luke and his team chipped away at Alice’s Upgrade Path, implementing the breaking changes that Infield surfaced, clearing the blocking dependencies, and finally upgrading Rails to the latest version. Infield’s impact was felt throughout the business:
- Time and Cost Efficiency: With Infield's guidance, the team saved around $8,000 to $30,000 in planning and troubleshooting time.
- Leveling up Developers: The clarity and direction provided by Infield made it feasible for other developers on the team to contribute to the upgrade process, democratizing work that had previously been reserved for long-tenured engineers. This also gave Alice the infrastructure to build a culture of maintenance into the Engineering organization.
- Enhanced Security: By bringing and keeping dependencies up-to-date, it became much easier and faster to remediate security vulnerabilities on an ongoing basis. According to Luke, accepting a security patch on a supported package is much easier than "figuring out if we are actually affected [by a vulnerability]. Okay, dig into the gem and look at whether we're using the affected code, go right to monkey patch, test the patch (if it’s even possible to). It just means you're spending way more time having to worry about vulnerabilities versus ‘there's a new version, let's upgrade.’”
On an ongoing basis, Alice plans to use Infield to keep dependencies up-to-date across their Rails app. Because Infield also gives the team visibility into maintenance status (abandoned packages, unsupported versions, etc.), they can use Infield to queue up application maintenance work that can be addressed in the course of a standard maintenance rotation. As Luke put it, Infield will help Alice avoid upgrade lag on an ongoing basis, “if I have a few hours to do some upgrades now, what should I prioritize? Infield helps me do that immediately.”
