At Intercom, we\u2019re focused on the future, and we\u2019re taking bold steps to get there. But when we make technical decisions, we like to be conservative.<\/p>\n
In practice, being technically conservative looks like reusing existing technologies and frameworks in our stack, or promoting tried and tested patterns and solutions. We value this familiarity because we understand that the important problems to be solved are the ones that deliver customer or business value.<\/p>\n
Instead of evaluating new technologies and spending time on already solved operational problems that ultimately provide little customer value, we can focus on improving the product by building, releasing, and iterating on solutions.<\/p>\n
This is the fifth post in a <\/span><\/i>series exploring our product principles<\/span><\/i><\/a>. Here, Waheed discusses our engineering principle \u201cBe technically conservative\u201d.<\/span><\/i><\/p><\/blockquote>\n
There are many long-term benefits to technical conservatism<\/h2>\n
This principle is best illustrated by a few examples from over the years, demonstrating how \u201c<\/span>Be technically conservative\u201d allows us to scale fast<\/a> while ultimately not being a constraint. I’ve spoken previously<\/a> about our experience of designing our reporting system, where we evaluated the benefits of introducing a new datastore to our stack \u2013 Redshift. It would have meant introducing a new type of database to our system that had never been tested against production. Furthermore, we would have had to spend a lot of time building up operational knowledge, maintaining clusters in production, and dealing with unforeseen issues from operating Redshift at scale.<\/p>\n
\u201c<\/span>We leveraged our existing infrastructure to speed up the process from an estimated six months to just six weeks\u201d<\/p><\/blockquote>\n
Ultimately, we decided that a familiar datastore was better suited to the job. We leveraged our existing Elasticsearch infrastructure, which powers the majority of Intercom\u2019s search capabilities, to speed up the process from an estimated six months to just six weeks.<\/p>\n
The initial version of the reporting system shipped a few years ago now so we\u2019ve had an opportunity to reflect on some of the longer-term benefits of our application of technical conservatism in that case:<\/p>\n
We solved the customer\u2019s problem faster<\/h3>\n
Using our existing infrastructure meant we avoided spending time familiarizing ourselves with a new datastore and dealing with all the inevitable hiccups. We were able to immediately focus on the customer problem to be solved, and shipped fast, reducing delivery time by more than four months.<\/p>\n
We made the most of the team\u2019s time<\/h3>\n
Our Data Infrastructure team were able to continue to focus on a small, familiar set of technologies instead of being spread across multiple technologies. As a result, they had \u2013 and still have \u2013 more time to ensure the health of our existing systems and optimize our use of each technology.<\/p>\n
\u201c<\/span>Because our set of technologies is relatively small, improvements happen regularly\u201d<\/p><\/blockquote>\n
We compounded the value of ongoing improvements<\/h3>\n
Because our set of technologies is relatively small, improvements happen regularly. The product leverages those technologies, and so the impact of those improvements is compounded across everything built on top of them. A tiny improvement can have a massive, positive ripple effect across the entire product.<\/p>\n
More teams have had more input<\/h3>\n
Using common technologies means that more engineers and teams feel confident and empowered to work with them. We\u2019ve seen frequent improvements to the reporting product from teams across the company rather than just one team that owns a particular part of the system.<\/p>\n
Remember that principles aren\u2019t rules, they\u2019re guidelines<\/h2>\n
Principles are an incredible way to align teams and have yielded great results for Intercom. But there are times when it might make more sense not to follow them. As a company scales, there is a risk that some team members will follow the principles dogmatically or interpret them incorrectly. Defaulting to technical conservatism should not mean that we never introduce something new.<\/p>\n
\u201cTechnical conservatism means favouring a technology that\u2019s already in your stack \u2013 but only if it\u2019s the best option\u201d<\/p><\/blockquote>\n
Technical conservatism means favouring a technology that\u2019s already in your stack \u2013 but only if it\u2019s the best option. In some situations an existing technology might not be suitable. If it can\u2019t answer the following questions, we might look further and evaluate alternatives:<\/p>\n
\n
- Does the new tool allow your business to scale more effectively?<\/li>\n
- Does it allow your team or org to move faster and deliver value more quickly?<\/li>\n
- Does it solve a customer problem that couldn’t be solved with your existing tools?<\/li>\n<\/ul>\n
If you answer \u201cyes\u201d to any one of these, it may be worth considering introducing that new tool. At Intercom, there was a recent example that answered \u201cyes\u201d to all three questions.<\/p>\n
Users, or our customers’ customers, are core to the Intercom platform. As we have grown, so have our customers and their needs in terms of how much user data they store within Intercom. The vast quantity of user data was leading to scaling issues with our current user datastore at the time, and to ensure we could continue to support existing and new customers we needed to rethink our current solution. That ultimately led us to introduce a new technology to our stack \u2013 here\u2019s how we arrived at this decision.<\/p>\n
We were scaling faster than our datastore would allow<\/h3>\n
We had been using MongoDB for roughly five years and had the operational scars to prove it. We had optimized every aspect of owning and running it \u2013 from the type of hardware it ran on, to the queries we ran on it. We were at the point of diminishing returns and were seeing strong signals that it would stop being fit for purpose within a couple of years \u2013 and might even become a bottleneck in the company’s growth.<\/p>\n
\u201cRegularly think about the trajectory of your business and ask \u2018<\/span>Will what got us here, get us there?\u2019. This<\/span> will allow you to be proactive about your choices rather than reactive\u201d<\/p><\/blockquote>\n
This is where having a strong, forward-thinking technical strategy is key. At this point we had enough data to suggest that we might need to evaluate another approach and had the runway to do it. Regularly think about the trajectory of your business and ask \u201cWill what got us here, get us there?\u201d. This will allow you to be proactive about your choices rather than reactive, and mitigates the risks around the unknown unknowns of introducing a new technology.<\/p>\n
Our technology was slowing down our team<\/h3>\n
At Intercom we strive to run less software<\/a>. In this case, even though we were adopting a new technology with unknown unknowns, adopting DynamoDB<\/a> allowed us to do just that.<\/p>\n
Previously, we were self-managing the scaling of MongoDB along with the code for balancing load \u2013 a significant overhead for the team. Part of the draw of DynamoDB was that it was managed by the vendor, AWS. This meant that, although there was an initial cost to adopting it, ultimately it would be cheaper and save the team a huge amount of time and effort.<\/p>\n
\u201cNot being dogmatic about technical conservatism enabled us to replace a technology with large overheads and limited capabilities\u201d<\/p><\/blockquote>\n
It may seem counterintuitive, but introducing a new technology ultimately resulted in us running less software. Not being dogmatic about technical conservatism enabled us to replace a technology with large overheads and limited capabilities with a new technology that was less burdensome operationally and more scalable.<\/p>\n
We were ruthless about requirements<\/h3>\n
We would sometimes require MongoDB to perform complex and expensive queries that risked availability and the performance of more common but less complex queries. When evaluating DynamoDB we realised that it wouldn\u2019t support those complex and expensive queries but it would be much better at the simpler and more common ones.<\/p>\n
We already mostly used Elasticsearch to perform complex queries, and the need to migrate forced us to review and more deliberately define the capabilities we required from our user store and ultimately allowed us to improve performance for its primary use case: retrieving single user records.<\/p>\n
\u201cWhen thinking about replacing a technology, don\u2019t take it for granted that you will use the new technology in the same way\u201d<\/p><\/blockquote>\n
When thinking about replacing a technology, don\u2019t take it for granted that you will use the new technology in the same way. Your requirements will likely have changed considerably over time, and the rest of the stack will have evolved or matured so that use cases become more narrow. This will open up opportunities to adopt more focused, performant technologies, or offload some technologies to be managed by a vendor.<\/p>\n
Make your principles work for your business, not the other way around<\/h2>\n
Technical conservatism is a great tool for allowing your teams to stay focussed on what\u2019s important \u2013 solving customer problems and delivering value without spending precious resources on answering questions that have already been answered.<\/p>\n
However, becoming too rigid in the belief that introducing new technologies is bad could prevent you from taking advantage of technologies that will help you run less software and scale more easily and quickly. It\u2019s important to apply this principle in a way that works best for your team, and your business, in the long term.<\/p>\n