We’ve grown. As of this writing, our Engineering Department is 35 strong, with folks spanning the gamut of skill sets, titles, seniority and tenure with the company. The entire Silverfin organisation is a mature business, with our platform used by thousands of customers as part of their daily operations. 

That’s a far cry from the early days when a small and fairly uniform group of people got Silverfin off the ground as a brash fast-moving startup. Back then, maintaining a common understanding on technical decisions, platform architecture, and trade-offs was relatively straightforward, even in a remote-first environment like ours.

As we got bigger, our collective alignment drifted and blurred. Some legacy habits failed to evolve in parallel with our changing reality. In other places, local optimisations sprung up that were not aligned with our strategic views. Newcomers didn’t always have clear guidance on how to adapt their previous knowledge and experience to their roles in Silverfin. We hit our low point when a couple of technical decisions made within teams had to be overruled and reverted, giving rise to confusion, frustration and wasted effort.

Recognising the need to address these challenges, we set out to distil the insights gained from our collective decades of product engineering experience into a cohesive framework. What enduring principles and battle-tested best practices produce sustained success? Which strategies and approaches foster development of robust, performant and sustainable solutions, and which are best avoided? We titled the resulting document “philosophy” - This is how Silverfin thinks about software engineering.

The first drafts were written by our VP Technology and Directors of Engineering. After a few rounds of feedback from our most seasoned engineers - the Engineering Strategy Guild and our Team Leads - we published the Silverfin Engineering Philosophy internally earlier this month. Here it is in its entirety, exactly as it was shared inside the department:

Silverfin Engineering Philosophy

Version: 1.0.0 (March 13, 2024)

Preface

This document is meant to be used to inform the hundreds of decisions, small and large, that engineers have to make during their work. It also explains why our system looks like it does, and in which direction future development and changes should happen.

Not everyone will agree with our current philosophy, and that’s expected in a group of people as large as Silverfin Engineering. We are all professionals, and our expectation is that everyone does follow it to the best of their abilities and uses it to inform their decisions regardless of personal opinions.

Not every past decision nor every piece of current code aligns with this philosophy. Sometimes this is deliberate, other times it’s because we’ve made mistakes. We don’t need to rectify all such misalignments proactively. Likewise, we cannot foresee everything awaiting us in the future. Changes to this philosophy or exceptions to our approaches will be made, albeit the threshold for these will be very high due to their wide and long-lasting impact.

Proposing changes

In a “recursive acronym”-kind-of-way, the process of changing this philosophy will be guided by this philosophy. Proposed changes must be pragmatic and practical, and rooted in our overall “Why”. Pitch a prototype of a change to validate it and get early feedback before investing effort that may be for naught.

Why

We start with “Why” because it underpins all our decisions about the “How” and “What”. “Why” is our goals, aspirations, and the reasons for our department’s existence, for working and thinking the way we do. By defining our “Why” first, we can be sure that the “How” and “What” don’t exist in a vacuum or represent arbitrary choices. Rather, every item in those categories is in service to our “Why”.

Our department exists in order to solve complex problems faced by our customers through application of software engineering and artificial intelligence. Our purpose is to provide comprehensive solutions to real-world problems: we aim to build quality houses, not slipshod shacks that fall apart when the first wind blows, nor over-architected castles no one needs.

We are here to use our skills to build innovative, useful and usable products for our customers. We are committed to ensuring stability, performance and long-term continuity of our platform as it underpins our entire organisation’s success and represents an integral part of our customers’ daily workflows.

How

We pride ourselves on our ability to strike the right balance between quality of our solutions, the speed at which they are delivered, and the cost to the business. Silverfin is a product-led company, which means that we focus on delivering concrete tangible solutions to our customers, in a way that keeps our maintenance costs under control.

We focus on the outcome: We approach our work with a sharp focus on delivering solutions that benefit our customers and our business. We firmly anchor our efforts to outcomes, constantly validating our ideas and prototypes before investing too much effort into them.

We are engineers, not theoreticians: We embrace real-world constraints and use them to guide our pragmatic, cost-effective approaches and allocation of resources. We work iteratively and build prototypes and proofs-of-concept out of matchsticks and duct tape that are at hand rather than reaching for the perfect tools and expensive materials before an idea is proven viable.

We make responsible choices: We acknowledge that every decision we make becomes a building block in our collective endeavour. Our daily choices shape the future of Silverfin, and we take this responsibility to heart.

We strike a balance between stability & adaptability: We rely on a carefully curated set of proven, robust and durable tools. We avoid all unnecessary complexity. At the same time, we are open to change; it is inevitable. But change must take place only in order to serve our goals, not in pursuit of novelty or for the sake of solving hypothetical problems that may never come. The costs of change and increased complexity must be weighed carefully and honestly against the benefits they are expected to bring. Over-emphasising stability leads to stagnation and inability to tackle new challenges. Over-eager adaptability risks destabilising our solid foundations. Too much of either can make forward progress slow and painful. Balance is key.

What

Pragmatism.

Not every problem or bug needs to be solved.

Perfect is the enemy of good. Good enough is often good enough.

Allocate effort for maximum benefit to business and customer.

Simple, pragmatic design allows us to build large and powerful systems without getting overwhelmed by complexity.

Return on Investment (ROI) is always an important consideration: a fix that goes 90% of the way for a tenth of the investment often may be the optimal choice versus resolving 100% for 10 times as much effort.

We gladly use things that are Not Invented Here (NIH). Our problems are not unique or special, someone out there will have encountered them before and might have a ready-made solution that we can use or tailor to our needs at a fraction of the cost we’d incur building something in-house. This effectively outsources maintenance to domain experts.

Tech debt is not inherently bad. Sometimes, creating technical debt is a reasonable short-term price to pay to deliver a solution efficiently. Mere existence of something perceived as technical debt is not cause for immediate fix or refactoring. If said debt is not incurring maintenance cost or slowing down further development, perhaps it’s not technical debt after all, just a pragmatic implementation.

Aggressive focus on low long-term maintenance costs. For software of Silverfin’s longevity, maintenance incurs a far greater cost than initial implementation. Low maintenance costs can be achieved through simplicity, small number of moving parts (dependencies, frameworks, languages), and ability to make frequent localised changes. Simplicity also allows us to have a streamlined and less expensive hiring process as we don’t need to recruit polyglots or multiple niche experts.