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
Patient Zero named finalist in three categories at ARN Innovation Awards 2025: Technical Excellence, Marketing Excellence, and Enterprise Innovation. Learn more.
At Gartner Gold Coast 2025, everything was about AI — automation, efficiency, disruption, predictions. AI, AI, AI. But in between all that noise, I found myself thinking about how I work, and how I’ve found working at Patient Zero. Some of the things they talked about, like trust, autonomy and team culture, are the things I’ve experienced here.
The Joy of Faking It - Reducing Security Risks in Legacy System Enhancement with Synthetic Data
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.
