Don't Build a Framework: The Build vs Buy Strategy

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.