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
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.
A friend and former colleague reached out to me recently to ask if I could help him fix a couple of bugs in a small project he’d been working on. He was not a developer, but had worked in and around developers for his whole 20+ year career as a business analyst, product owner and program manager. With the advent of tools like Cursor and Lovable his lack of coding ability was (maybe) no longer a barrier to getting some ideas he’d been incubating in his mind for a while, out into the world. With credit card in hand, he dived headfirst into the world of “vibe” coding. We met for coffee, and he showed me the prototype he’d built. I was quite impressed with what he showed me (running on his laptop…deploying it anywhere was a bridge he had not crossed yet) – a capable working prototype that demonstrated the ideas he was trying to prove out. I asked him about the “development experience” and he said it had been great at first, and he’d been able to make a lot of progress quickly, but at some point he hit a bit of a wall where each change he tried to make introduced more issues, and he felt like it was pointless to continue. He’d switched between a few different AI coding tools in an effort to see if the problems he encountered were specific to the tool he’d started with, but without success. The vibes had run out.
Making cybersecurity fun and engaging with capture-the-flag (CTF) events—boost team collaboration, enhance security skills, and turn dry security practices into an exciting challenge!
