Lessons from Lyons Davidson: When Framework Abstraction Goes Wrong

One of the most valuable lessons I've learned in my career didn't come from a technical book or a mentor—it came from a misstep. While working at Lyons Davidson Solicitors, I was actively building out reusable components to improve the consistency and maintainability of our Silverlight-based systems. I saw opportunities everywhere to clean up duplication and streamline development. It felt like progress.

That's when I made a classic mistake: I changed a static class into a singleton.

On paper, the change made sense. We needed to manage state more deliberately, and introducing a singleton would allow for better encapsulation. What I didn't do, however, was check how others were using that static class across the application.

The result? I broke things. A lot of things.

The issue wasn't the singleton pattern itself—it was the assumption that the static implementation could be swapped out without consequence. Other developers had built logic around its stateless nature. Introducing state, even indirectly, had unintended side effects across multiple parts of the codebase. What seemed like a clean architectural improvement turned into a team-wide scramble to patch and fix regressions.

That moment has stuck with me. Not because it was a technical failure, but because it was a communication failure. I didn't socialise the change, validate its usage, or explore the broader implications. It taught me that framework development isn't just about good abstractions—it's about empathy, alignment, and stewardship.

Since then, I've carried that lesson into every role. Whether I'm introducing a new service abstraction, refactoring shared utilities, or creating reusable UI components, I ask myself two questions: Who's using this? And how?

The best frameworks don't just work well—they work well for others. They make the developer experience better, not worse. They respect existing workflows while guiding teams toward better practices. Most importantly, they evolve with consensus, not just conviction.

So if you're in a role where you're building frameworks or shared libraries: take a beat. Speak to your team. Review the call sites. Document your rationale. It'll save you more time—and goodwill—than any pattern or principle ever could.