Finite State Machines (FSMs): Replacing Complexity with Stateful Simplicity
This article talks about Finite State Machines: what they are, how they work and why they’re importantLife is complex. And with money being both the glue that holds society together and the fuel that helps it develop and grow, finance must be equally complex.
But is it excessively so?
It’s hard to definitively say, as often this complexity serves a real-world use or need. I am convinced, however, that we can and should build better tools that abstract this complexity where appropriate, and inform and guide decision-making where it is not.
One idea we are using at Better to accomplish this is the finite state machine (FSM).
What is a finite state machine?
A simple example of a finite state machine is a traffic light.
Traffic lights can be in one of three states: RED, YELLOW or GREEN. You also know that GREEN transitions to YELLOW, YELLOW to RED, and RED back to GREEN. This combination of states, and transitions to next possible states, is what constitutes a finite state machine (FSM).
For our simplified traffic light, these transitions are driven solely by the passage of time. In other situations, FSMs can have a huge variety of different drivers. Consider the process of uploading a contract for a property purchase. Once this contract has been written and uploaded, it could be considered to be in a state called PENDING. Signing this contract would then transition it from PENDING to COMPLETE.
Defining these states and transitions is quite mechanical, but if you can describe a process in these terms, you can easily represent it in code. In an ever more digital world, being able to describe business processes in both an intuitive and computer-friendly way is incredibly valuable as it facilitates better understanding amongst all stakeholders. You don’t need deep or specialized computer literacy to understand how an FSM process works.
Another benefit of using FSMs for software development is that it forces us to take a step back and view a problem from a more holistic point of view. It requires more upfront work – we need to have names for and an understanding of the entire process – but this abstract representation is easier to understand and modify. Thinking in holistic terms also helps us to find broader patterns in some of the business logic flows that we support.
Lastly, the code that we end up writing in many cases is actually simpler; we make the tradeoff of adding ‘statefulness’ to our system for less complex logic. We now, however, need to consider that state when making changes to the system down the line.
How we use FSMs at Better
We’ve recently reworked the core logic behind our real estate transactions. Over time the previous version of the logic had evolved into code that was messy, complex and generally difficult to work with. After speaking with stakeholders, we were able to rebuild the logic as an FSM, greatly simplifying the flow of our code.
We used our own FSM framework for this project; one that promotes reusability and composition. We tested both the old and new versions of the code where the lifecycles overlapped, and used the strangler pattern to seamlessly start using the new system for new transactions.
But the potential of this FSM extends far beyond just reworking core logic. We are considering visualizing our transaction lifecycle by directly reflecting over the code, adding automatic instrumentation for metrics and observability, and programmatically exposing the structure of the FSM for our front-end teams.
This last extension is an interesting one from a user experience perspective. As we’ve defined the transitions that are possible from any state, we now have a good sense of the possible actions a user can take from any point in that process, allowing us to more systemically guide our users’ workflows.
The future of FSMs and tech at Better
The software engine that powers Better is called Tinman and was already utilizing FSMs and related ideas to make implementation of complex flows and processes simpler, faster and less error-prone. This modeling and abstraction that is core to FSMs will be crucial for continuing to scale our offerings, processes, and team.
FSMs are just one of the ways we try to more quickly iterate and deliver value at Better. Our cloud, open-source, and infrastructure-as-code based stack (AWS, Docker + k8s, Terraform) also helps in this regard. This, and other practices, helps us to better leverage technology to provide a more intelligent, holistic, and intuitive path to home ownership.
If you’re interested in helping simplify home ownership and finance, good news: Better is looking for new team members right now. Visit our careers page to find out more.
Our thinking
Upserts in Redshift
Redshift doesn't support upserts (updates + inserts) but using a few tricks we can implement it anyway.Wed Aug 28 2019—by Erik Bernhardsson1 min read- sql
- python
The Growth team did what to the website??
And you won’t believe the results!Fri Oct 02 2020—by Koty Wong5 min readEngineering a Diverse Team: Taffy Chen and Jimmy Farillo
Software engineers Taffy Chen and Jimmy Farillo launch a new blog series to showcase different perspectives on the Better engineering team, and the ways they’re working to make it even more diverse and inclusive.Fri May 14 2021—by Taffy Chen and Jimmy Farillo2 min read- diversity
- inclusion
- perspectives