From Silverlight to Microservices: My Evolution as a Framework Developer

My career in software development has followed a path that, looking back, feels deliberately paved by a focus on scalability, reuse, and developer experience. One of the most pivotal stages in that journey was my time at Lyons Davidson Solicitors. It was there that I transitioned from being a developer who implemented features to someone who thought deeply about how code is consumed, reused, and maintained across teams and systems.

When I joined Lyons Davidson Solicitors, Silverlight was still alive and well. Our systems were built using Silverlight for the front end, supported by WCF and ASP.NET MVC in the back. At first glance, it was a fairly typical enterprise stack for the time. But as I dug deeper, I started to notice a pattern: repetition. Authorisation logic, in particular, was duplicated across different views and components. The inefficiency of that repetition set off alarm bells in my mind and pushed me to explore how shared logic and reusable packages could alleviate some of that pain.

I began to experiment with building shared packages that could be reused across Silverlight applications. The goal was simple: centralise logic, reduce duplication, and make our codebase easier to maintain. This early attempt at framework thinking exposed me to the challenges of abstracting functionality in a way that serves the many without breaking the few.

One of the most significant outcomes of this was a framework I built for database access. Rather than continuing to write the same classes over and over for each data operation, I used reflection to inspect types and dynamically map data. This approach reduced our codebase by as much as 70% in some areas. More importantly, it set a precedent for my approach to problem-solving: if something feels repetitive, abstract it.

But it wasn't all wins. I once changed a static class to a singleton without consulting anyone. I thought I was solving a technical problem, but what I hadn’t considered was how other developers were using it. The backlash was immediate and justified. That experience taught me one of my most important lessons: understand the use case before you change the implementation.

Framework development isn't just about writing reusable code. It's about empathy. It's about putting yourself in the shoes of the person who will be using your abstraction, and ensuring that what you build enhances their productivity rather than hindering it.

The seeds planted during that time at Lloyds Davidson eventually grew into a deep-rooted belief in modular architecture. My later work in microservices, domain-driven design, and distributed systems owes a lot to those early experiences. In fact, I often refer to myself as a "framework developer" not just because I write frameworks, but because I think in frameworks—in boundaries, contracts, and composition.

Today, when I mentor junior developers or design architecture for growing teams, I always return to those principles: minimise repetition, maximise clarity, and never make a change without understanding the consequences.

Looking back, Silverlight may have faded into obscurity, but the lessons I learned while working with it continue to shape my career in profound ways.