Chesterton’s Fence: A Principled Approach to Development of Fintech Software
All financial software deals both with the past (existing tools, data, and third-party integrations) and the future (inevitable changes in scope, growth in customer base, and more). This means that fintech software is often in a state of flux. This is never more the case when a long delayed update takes place, and a new team steps forward often creating a fraught situation, where the wrong approach can break working code, and leave partners and customers in the lurch.
What guiding principle do the best fintech software developers use when they add new features to legacy code or even replace it? Here’s one big one: Chesterton’s Fence, which says that change should not be made until the reasoning behind the current state of affairs is understood.
G.K. Chesterton and His Fence
The term Chesterton’s Fence gets its name from G.K. Chesterton, the late 19th-century and early 20th-century writer, who was writing about reforming existing institutions and practices and articulated an analogy: it’s rash to come across a fence and tear it down without understanding why it was put up. If you understand the reason for the Chesterton’s fence (for example, a process that double checks data or pushes code to staging before production), and you know that the reason no longer applies, you can make changes. However, if you don’t understand the purpose of existing practice, you need to do more research before tearing down a structure that might have a very important current role.
In fintech, the potential losses from making mistakes are so large. For instance, missteps like failing to execute a trade, executing a wrong trade, miscalculating a deposit or transfer, or allowing an attacker to inject commands or exfiltrate data or money can be monumental, so preserving existing guarantees is a top-tier principle. A bad case is ripping out or replacing something that was load-bearing and then learning immediately because the system doesn’t work anymore. The worst-case scenario is ripping out something (perhaps for the sake of false efficiency) and seeing that the system appears to work just fine but that some subtle but important guarantee that was being made no longer holds true. At that point, the time bomb has begun ticking, but no one knows it — yet.
Long Beyond Shrinkwrapped Fintech Software
Your financial software may have grown beyond the shrinkwrap stage a month ago or decades ago, but no matter how long it was, the new push to scale, improve, or add capability had to take months or decades of development seriously. It’s always tempting for a new developer on a project to look at a series of rules, transformations, or steps and think, “This is just needless complexity; before I add new capabilities, I’ll bulldoze this flat, make a nice, clean foundation, and then build upward.” But that way of thinking is a mistake.
Bulldozing Flat is Not Always the Answer
When the best fintech developers come across a system, code, or business process, they will question why it became that way before implementing change. One can think of this as a character issue — a matter of empathy and curiosity — but these traits can also be developed and consistently implemented by training and practice. Slowing down, analyzing code or practice, and asking questions often reveals the purpose of the code, which is the reason for this particular focus on the Chesterton’s Fence principle. The result of this technical archaeology is often surfacing an existing stealth requirement — perhaps one that no one else currently on the team even knows about!
What sorts of reasons lie behind these stealth requirements? What’s the method to the (apparent) madness? Those experienced in this area have their war stories; for example, perhaps earlier developers tried the “obvious” approach but encountered usability challenges. Perhaps there are regulatory constraints that mean that the simple approach can’t be used. Maybe there’s a security issue with doing things one way, and this is obviated by doing it another way. Perhaps data is being checkpointed or logged for compliance. It could be that an important computation is intentionally being done twice so that the results of one approach can be sanity checked against another. Maybe there’s some partner firm that requires data to be formatted in a certain way or requires that the people they do business with perform processes according to some specifications. You get the idea: The list of reasons is endless.
Stop, Look Both Ways, and THEN Proceed
Whatever the reason, the upshot is that the rule of Chesterton’s fence must always be obeyed. Your fintech developers should not just rush in to make changes — rather, they should thoughtfully consider the reasons behind the existing practices and code by gathering data, asking questions, and acting in a consultative role.
If your developers are heeding Chesterton’s fence (which might be as involved as running tests on the existing code base or systems to see exactly what invariants are being obeyed), they’ll get the data from forensics, code reviews, interviews, and reading documentation that they need to make a decision.
Sometimes, they may decide that the reasons for the oddity are no longer valid and that they’re free to make changes.
Other times, your developers may decide that the broad outlines of existing processes must be maintained, but the exact details can be tweaked (rewritten from one language to another, ported to a new machine, parallelized, etc.).
And every now and then, they’ll make the prudent decision that one particular part of the architecture needs to be kept exactly as it is (if, for example, a partner is sharing data through an API or other mechanism that has very precise constraints on versioning or other details).
All of this takes a certain degree of maturity, both in character and in work experience. The kind of fintech developer you want to work with should seek understanding before implementing broad-scale change. Only in this way can you be assured that software implementations work the way your business does — now and in the future.
Fintech Developers: Discover the DBA Difference
A firm that’s not experienced in working with existing mission-critical codebases is not likely to approach these questions with the appropriate sense of humility. Just as architects love to design exciting new buildings, developers love to build new applications! Going slowly and thoroughly understanding requirements isn’t always fun, but it’s absolutely crucial to delivering the right product to the customer. Our fintech developers take the principle of Chesterton’s Fence seriously and apply it in every approach.
This is one of the things that sets DBA apart.
DBA has years of experience modifying legacy code to accomplish fintech goals. Our developers take caution and establish a thorough understanding of your codebase as well as your business needs and goals to design a fintech solution in a staged and safe environment. To learn more about our approach, book a meeting.
