At some point in the lifetime of a product development comes the moment where software engineers have to break old assumptions and replace them with u

What we learned from a large refactoring

submited by
Style Pass
2022-01-13 12:00:06

At some point in the lifetime of a product development comes the moment where software engineers have to break old assumptions and replace them with updated ones. At Alan, we are undertaking a large refactoring to update one of the oldest assumptions in our code base. As we are nearing its end, we gathered some learnings during our journey on how to achieve this kind of change.

Alan is an insurance company: it p rovides health services to companies. In practice, this relationship between Alan and companies is represented by a Contract. Since Alan’s beginning in 2016, the product has been built on a core assumption: a company can have only one single contract at a given time. At that time, all our customers validated this hypothesis.

At the end of 2019, we started having a few companies needing two contracts. They wanted to provide different insurance contracts to different subset of employees. Since we didn’t have enough volume to justify a lengthy refactoring, we kept the single contract relationship and managed to handle these rare cases using a hacky way: by creating two companies to represent a single “real” one.

Starting 2021, the number of companies with two contracts has greatly increased. And the technical debt due to having two companies representing the same single real-life company has become hard to maintain. At the same time, our sales team signed a deal with a large company that needed not only two, but eighteen different contracts. This was time to challenge our past hypothesis and move to a multiple contract world.

Leave a Comment