Move Fast And Don’t Break Things
This article is the first in a series, showcasing a number of examples where the development team at Flock have used strong static type systems to achieve the goal of moving quickly and not breaking things.
This series is for anyone interested in static type systems and pushing the boundaries of type safety in TypeScript. For any developer that has tight deadlines and wants to find a way to deliver at pace whilst ensuring that what they deliver is correct.
Defining a company value
Much has been said about the famous Facebook Motto Move Fast and Break Things, with plenty of people weighing in on the underlying philosophy, it’s validity and possible faults.
At it’s core, is the idea that companies need to move fast to take advantage of opportunities and they need to not be afraid of making a few mistakes along the way as this prevents you from working at the speed required. Zuckerberg himself has been quoted as saying “The idea is that if you never break anything, you’re probably not moving fast enough.”
Back before Facebook went public this motto was supposedly prolific on posters around the company’s office and appeared prominently in paperwork released in preparation for going public.
Over the years, as Facebook has grown in size, it seems to have had a slight change of heart, ironically updating the motto to Move Fast With Stable Infra. A far less catchy sounding motto but expressing the desire that correctness is important to a business. Correctness here, is that a system under predefined conditions produces an expected outcome.
In the tech team here at Flock, we ran a values session to understand what it was that we as a team believed in. What values did we feel were necessary to help us achieve our goal of becoming a next-generation InsureTech? What culture did we want to uphold and propagate that could revolutionise the insurance industry?
One of the values to come out from this session was _Move Fast and Don’t Break Things_. Partly a tongue in cheek homage to the original Facebook Motto, the sentiment behind the idea was that as a start-up we need to move quickly but also need to limit mistakes. It’s a problem faced by virtually every start-up to have existed. How do we deliver fast enough to corner our niche in the market but importantly, due to FCA regulation and the nature of our industry, limit mistakes?
As a team, we have undertaken a number of approaches, utilised a host of technologies and explored a variety of techniques to help us achieve this goal. One, in particular, has been a resounding success and that is utilising strong static type systems throughout our engineering works.
This may seem contrary to the belief in moving fast as dynamic type systems are more commonly utilised for rapid development. Alan Kay, the creator of Smalltalk, has been regarded as saying “I’m not against types, but I don’t know of any type systems that aren’t a complete pain, so I still like dynamic typing”. However as a team, we have come to believe that, whilst dynamic typing generally has a faster start up time, you are ultimately slowed down when constrained to produce correct code.
We have found that ensuring the correctness of dynamically typed code usually requires more case consideration and that testing usually requires more unit tests to cover the multitude of cases. In general dynamic typing requires extensive unit testing to prove correctness and even then these unit tests are often only sufficient at proving the existence of bugs and not their lack of existence. Additionally for dynamically typed languages, there can be a lack of IDE support making the developer experience more cumbersome.
There is a much wider debate possible about the pro’s and con’s of different type systems and when each is applicable, however, I am not looking to delve into this. As mentioned above, here at Flock we’ve found that strong static type systems have really benefited our team.
In particular, there are a number of key examples and lessons we’ve learnt over the last few years that we’d like to share.
We will be looking at three key examples:
- Adding run time type validation to IO actions in TypeScript
- Domain Validation and using opaque types
- Modelling tree-like state flows at the database layer
Each of these examples will be considered in a separate article and will take us on a journey from the outer layers of our application through the domain logic and end up within our persistence layer.
The first of which will look at a core issue with TypeScript. That being that JavaScript is the language that is executed at run time. We will show by way of example, how despite producing seemingly correct TypeScript code we can still create incorrect output quite easily by using incorrect types. We will then show how we have combatted this by adding run-time type validation.
In the second article, we will look at how we use types to model our domain and push validation to the boundaries of our system. Here we will demonstrate the strength in knowing our data is correct as quickly as possible and then how we ensure the right data ends up in the right place.
Finally, we will discuss how we store complicated state flows, specifically tree-like state flows, in our persistence layer. We aim to show how we structure our database schema in such as way as to ensure that only correct data can be entered into the persistence layer.
