What do travel benefits and a re-imagined employee expense system have in common?
Other than being beneficial to small- and medium-sized businesses, they’re both products of teams that define engineering best practices in a way that allows them to fail fast and scale quickly. For evidence of the success of those methods, look no further than the software itself. To learn how each company deliberately reduces repeated error, we asked the director of engineering at Hopper and SVP of product development at Abacus to walk us through their pipelines.
Booking flights can feel like an either-or situation. For a small fortune, the most convenient dates and times are yours (9 a.m. on a Saturday morning, please!). Don’t mind a three-hour layover in Michigan from California during a blizzard? Good, because the fees are pretty reasonable for that route.
Hopper’s machine-learning-based prediction software means those two options don’t have to be mutually exclusive. Not only that, but they’re expanding service offerings. Alex Campeau, director of engineering for their hotels’ division, told us how they fold old practices into new models.
How does your software development team define their best practices?
Hopper is scaling very quickly. As a result, our best practices often need to be revisited as our needs continuously change. We understand that we need to maintain speed and agility as we grow, so we focus on mechanisms that give teams as much autonomy and ownership as possible. That being said, we make sure teams have the proper support and don’t have to reinvent the wheel if they don’t need to. Engineers share insights and best practices through special interest groups, which allow engineers of different teams to learn from one another on specific topics like development processes and technology stacks.
Teams have different needs depending on the maturity of the product they are working on.’’
How does your team balance a need to incorporate best practices into their work with the desire to try and test new methodologies and strategies?
Teams have different needs depending on the maturity of the product they are working on. We’re currently experimenting with car rentals, starting to get traction on our hotels business and working to have a more established flights product. In the early stages, teams needed to be creative, think outside the box and try a lot of things (that often failed). On a more mature product, best practices, maintainability and scalability become much more important. Teams tend to rely on these qualities more because they help onboard engineers at scale more efficiently and provide a solid technical foundation for the product to evolve.
If expense reporting seems simple to you, you probably don’t have a hand in it. That’s why Abacus is changing the game when it comes to automating the process of reimbursements. We recently spoke with Joshua Halickman, SVP of product development, about how their engineers leverage technology as much as possible to build the software their clients use.
How does your software development team define their best practices?
One of our team’s core values is “quality by convention,” which means that we collectively believe that following best practices and standardization will directly lead to a higher quality product. To that end, we define and enforce such best practices in a few different ways. First, we try to leverage technology as much as possible through linting rules, commit hooks and tests. For things we cannot lint for, we look to reduce the number of ways to accomplish the same pattern. This narrows our focus, which leads to a better understanding of how we do things and why.
We also try to find the smallest way we can experiment with a new process and fail fast.’’
How does your team balance a need to incorporate best practices into their work with the desire to try and test new methodologies and strategies?
We believe strongly in consensus-driven best practices. When we want to try new methodologies or strategies, one engineer will bring it to the rest of the team via a proposal (usually in the form of a GitHub issue), and the rest of the team can respond. We also try to find the smallest way we can experiment with a new process and fail fast. For example, we might begin with test code before affecting production. When we are evaluating new technologies, we use a questionnaire developed by Kellan Elliott-McCrea.
