Don't Build A Framework
Paul Seymour • June 14, 2018
We all try it; I’ve never once seen it succeed. I’m not talking about choosing a tech stack, or settling upon a standard architecture. I’m talking about a bespoke collection of internal libraries and branches of popular libraries, patterns and architectures that eschew the “standard” conventions in order to increase the productivity and quality of the development team. So in a world awash with development frameworks, why is it a bad idea to build another one?
The most productive off-the-shelf frameworks are highly opinionated, there is generally just one “right way” to do something, and that information is public knowledge. Internal frameworks are often highly opinionated also, but knowledge about “how” is often hidden or difficult to find. Developers can’t easily find solutions to their problems, and as a result productivity is much lower.
There is an interesting parallel in game AI research. There are essentially two types of games – games with full public state, such as noughts and crosses or chess (where both players have full knowledge of the board). And games with hidden state (such as card games, where you only know your hand). Traditionally AI research has focussed on the former as it’s much easier to solve – you can find and weight all the solutions and pick the best one. These AI’s will consistently beat even the best human players. But until recently, that’s not been case with hidden state games, good human players will usually beat the AI.
Here are some of the warning signs that you might be about to vanish down the framework rabbit hole:
- There is a feeling that your business is unique from technical or compliance perspective
- You have a new application, but it won’t work unless you build a framework
- You start hearing terms like “metadata driven” and “self-configuring”, but you still seem to spend lots of time configuring things
- You can’t solve business problems until the framework has been built and stabilised
- You can’t use the PaaS or the cloud because your customers won’t let you
- You are thinking about taking an existing, opinionated framework and improving it
If you have built a framework, this is the likely outcome:
- The framework is never complete
- The framework consumes significant development resource just to keep it working
- The framework never delivers the productivity or quality you believed it would
- Business applications are limited by the capabilities of the framework
- Developers are often blocked in their ability to solve their problems; they depend upon a few key people within the organisation that understand the internals of the framework
Here is what a healthy development project looks like from a framework perspective
- A new developer can pull down a repository, build and launch it without any input other than installing the development tools (in the .NET world we call this F5 Go)
- Developers can Google their problems and speak with the authors of popular, open source libraries
- The infrastructure and platforms used to run an application are entirely disposable. PaaS and Docker make it dead simple to throw away and recreate the entire environment on every build
Frameworks are great, they save thousands of hours in developments time and solve problems that no single team could realistically solve. Internal frameworks will often emerge organically out of an eco-system of applications – and that’s fine. You have working applications; you can see clearly where there would be benefits in standardising and sharing functionality, and you can measure the cost of that. But unless you are Google or Microsoft, don’t start a project by building your own framework.
Share This Post
Get In Touch
Recent Posts
GPT-5 - the highly anticipated latest version of OpenAI’s hit the streets a few weeks ago. Despite of some breathless commentary from influencers who had been given early access, the eventual release was a bit underwhelming (in a way that only something that would have seemed like science-fiction a few short years ago but now seems passe, can be). Aside from the quality of the model itself, which some people have claimed was more about lowering OpenAI’s costs than delivering a better result, there are some issues that the change to GPT-5 has introduced when integrating it into a product which we thought we should share.
The ability to preview files directly within a web application is a major enhancement to user experience. Enabling users to view uploaded documents or images without needing to download them first saves time and reduces frustration. This can be a game changer in document-heavy applications where users frequently and recursively review and upload files through the interface. There are many libraries, packages, software subscriptions, and external API services (you name it!) that exist to solve this problem. But when spoiled for choice, it can be difficult to decide on which kind of solution best fits your application’s needs. This article explores this conundrum in the context of .NET Core web applications, with a focus on their specific quirks and requirements.
We’re proud to announce that Hanieh Madad has been named the winner of the Technical Award at the prestigious 2025 ARN Women in ICT Awards.
At PZ, we’re always exploring how design and technology can better complement each other. We recently hosted a Lunch & Learn featuring Emma Carter, Experience Design Leader and author of DesignedUp, whose talk was a candid, experience-rich exploration of what it takes to create great products, and even better collaboration between disciplines.
