Amherst’s engineering and product team is aiming to scale Everest by 2021.

While the team at the Austin-based real estate outfit isn’t ascending the actual immortal mountain, they are embarking on a formidable upward climb: building out a monorepo — under the project name “Everest” — to consolidate their code and improve workflows.

Monorepos, one big code repository that houses every project across a company’s tech stack, have gained momentum in recent years, said Amherst’s Software Engineer Corey Berigan. According to teammates, Amherst’s monorepo was born out of frustration with slow workflows that stymied developers and impacted tenant experience. 

As the company expanded, and the number of teams, projects and repositories swelled — what Berigan characterized as a “web of dependencies” — the speed at which Amherst was completing projects had slowed. 

“Before Everest, a lot of the processes involved manual manipulations, running different reports and many handoffs,” Product Manager Jubin Thomas said. “Moving those processes onto Salesforce allows us to streamline those.”
 

Employees will be presented with what they need to do their job at the moment they need it.”

According to Senior Product Manager Joseph Dentrone, streamlining internal workflows will result in external success. 

“Employees will be presented with what they need to do their job at the moment they need it. We want to be able to give tenants that same benefit,” Dentrone said. “If they have a work order outstanding, we want to notify them the moment a work order has changed. The goal is to improve the tenant experience as much as possible.”

With a targeted completion date of 2021, there’s still plenty of ground to cover. As they continue to develop, test and iterate on the undertaking, Berigan, Dentrone and Thomas shared how they’re summiting the project’s peak. 

Growing pains

Duplicated code. Cumbersome processes. Headaches abounded in the pre-Everest days.  

Berigan: As a company grows, you have a lot of teams. You have different applications, but they have some similar underlying patterns. That same kind of work is duplicated in other projects. It’s often hard to make that functionality available and communicated to other developers. You don’t know about a package that another team made. After a while, code becomes duplicated.

Also, there’s a lot of overhead in deployments. If you deploy some service, and you make a change to it, then there’s deployment to another service that requires attention. DevOps has to keep track of all that stuff and make sure that they abide by the order of operations that won’t mess anything up.

Thomas: It can be a complicated customer journey. Everyone realized that in order for us to scale and be as efficient as possible, this is something that we needed to tackle.

MORE ON AMHERSTMeet Amherst’s CTO: The Hardware Junkie and Code Captain

Providing the solution

SVP of Engineering Jason Griffin pitched a monorepo as a panacea to the organizational woes, providing a more fluid alternative to discordant platforms and repositories that would iron out operational inefficiencies.

Dentrone: Everest is a way for us to consolidate several independently created applications into a consistent UI — Salesforce, for the business — and any other custom applications being held on a single repo within AWS.

Thomas: A lot of businesses aim to get that 360-degree view of the customer. This will allow us to reach that goal.

Berigan: We want to get a glance of all the pieces of code that are being used so that we can reuse it in several parts of the infrastructure a little bit more easily. For code review, any feature change that may affect several applications or parts of the back end will be all in one place. The idea is to have one code review for multiple deployments. If there’s a back-end service that affects multiple front-end apps, it’s a lot easier to see everything in one spot. 

Also, there’s data governance. With certain applications, there’s different representations of properties, and each project has its own definition. We’re trying to unify that into one code base so that we only need to define a property once and use it everywhere.

The eyes on Everest

After weighing the pros and cons of the project, buy-in was secured, and the team got to work prototyping before writing the first code in September 2019.  A “platform squad” helps keep Everest moving, and their development is tactically phased out and released to certain teams in waves. It’s a delicate line to tow: Dentrone said it’s vital to update tech without disrupting legacy apps whose stoppage would jeopardize the tenant experience.

Dentrone: We named the project after different milestones on an Everest climb. Our first phase, Basecamp, was released to the leasing and renewals teams at our property management company in March. Now we’re spreading the Salesforce UI amongst different teams within the property management side because each one of them has its own unique workflow.
 

The idea is to have one code review for multiple deployments.”

Berigan: We’ve formed a platform squad, which is essentially our governance squad. Our primary responsibility is to make sure that we know everything that’s going into Everest. How does this piece of code fit into the repository? What is this data model? We’re kind of the eyes on Everest. 

Thomas: We meet with business units according to our product roadmap. We do discovery, understand what their current processes are and model out what they’ll look like in an ideal world within Salesforce. We pilot it out, get continuous feedback, make corrections and then move on to the next major workflow.

Words of wisdom

Though the project is far from completion, the team’s already gleaned a few best practices for implementing a monorepo.

Thomas: On previous product development teams I’ve been on, we’ve tried to create everything from scratch. Anytime you want to make changes, it then requires a lot of coordination. With applications like Salesforce, where we can implement processes and workflows using out-of-the-box tools, we can quickly make changes on the fly.

Berigan: Come up with a good deployment pattern. If you change one line of code in one service, you want the deployment process to be smart enough to deploy only that service, instead of deploying and testing the entire company infrastructure for one little change.

Also, test your code. If a piece of code only affects ABC, you don’t want to test XYZ if it’s not needed.

Dentrone: Sell the end user on the changes as much as you spend on selling the decision-maker. End users will go to bat for you if you can convince them that this workflow is better. They will help you convince the managers that it’s better; then, things can actually move forward.