WTF is a Framework?
(What follows is an extract from Out of the Software Crisis)
WTF do you mean when you say ‘framework’? #
One of the most common abstractions in software development is that of a framework. They dominate web development and are a growing part of app development as the business need for cross-platform solutions becomes more and more pressing.
They are a key part of any given software development system, even the ones that aren’t technically using a framework.
What a framework is, precisely, is notoriously hard to define. They’ve been defined as ‘code that calls your code,’ or ‘structure you can build your software on,’ or ‘a third-party platform for developing software applications.’ Most definitions leave out entire classes of frameworks, and few offer definitions that are useful.
In software, a framework encodes a particular approach to thinking about and solving problems in software development.
Those approaches are paradigms, also known as worldviews, controlling ideas or mental models, formed through examples of practice. The term originates in Thomas S. Kuhn’s The Structure of Scientific Revolutions (2012), as a description of how science progresses by switching from paradigm to paradigm as each model progressively better explains reality as we understand it through practice and experimentation.
Kuhn’s paradigms differ from software paradigms in that science is constantly driving towards a better, more objective, understanding of reality, whereas software paradigms are generally relative to the problems they are trying to solve. That’s why multiple conflicting software paradigms can coexist (relatively) peacefully.
A software paradigm exists outside of software, as a mental model or controlling idea that directs software practice. They differ from a scientific paradigm, but the overall concept remains similar:
- It is a worldview or framing for how to think about an aspect of programming. Sometimes it’s holistic and encompasses the entire stack that the developer is likely to interact with. Sometimes it’s specialised and applies only to a part of that stack, like storage or rendering.
- It is defined by example and by the discourse surrounding the examples.
- As with Kuhn’s scientific paradigms, it is open-ended, allowing practitioners to explore applications of and variations on the paradigm as they see fit.
Ultimately, a software paradigm is a blueprint for a software development system and a framework is a particular implementation of that system or one of its subsystems. This is the system whose stocks and flows we talk about when we talk about the value of code and designs.
Those frameworks range from the purely paradigmatic to the purely systematic. Paradigmatic frameworks only exist as documentation and examples of practice and leave the actual system implementation to you. Systematic frameworks exist as implemented systems that your code has to function entirely within.
Programming without a guiding paradigm is just random and haphazard code. You have a process, experienced developers, and great research, but without a controlling paradigm, you are unlikely to be able to integrate them into a functioning software development system. You will need a paradigm if you’re going to get anything done. The easiest way to get there is to use a framework.
Paradigmatic versus systematic frameworks #
A classic paradigm in software development is the Model-View-Controller (MVC) architecture. It defines how you should structure your application, where the business logic should reside, and how it interacts with the user and platform.
At a high level, the concept is (almost) straightforward:
- The Model controls and manages access to the data store (however that is implemented). It validates data and responds to queries.
- The View controls and manages the user interface. It manages visual state and responds to events.
- The Controller mediates between the two, updates the View with data from the Model, and contains the application’s actual business logic.
The details of an MVC system can vary enormously. Do you have a lightweight controller and put most of the logic in the Model? Do you let the View fully manage its visual state, or does the Controller take care of that? How do you manage object inheritance? Do you use delegates to mediate between the View and the Controller?
You can implement an MVC-based app without a systematic framework, in a purely paradigmatic way, just with some way of accessing data, a rendering surface, and an object-oriented programming language. MVC is still a framework when you do this because frameworks don’t have to be fully systematic. You still have a system based on a paradigm. You just happen to have implemented it yourself.
A purely paradigmatic MVC framework would consist of documentation, with examples, for implementing an MVC architecture in a given programming language on a given platform.
A purely systematic MVC framework would, for example, be when a platform bakes Models, Views, and Controllers into the APIs it provides. Going with a different paradigm would entail working against the system, or going outside the platform’s system entirely. Apple’s ‘Cocoa’ APIs, for example, form a consistent and comprehensive MVC programming framework, which was one of the reasons it was such a productivity boost when it first appeared.
Paradigmatic frameworks are defined informally or through detailed documentation. They tell you which specific affordances and capabilities of the underlying platform or framework you should use and which you should provide to other parts of the system. They minimise the time spent deciding on approaches. They make your work much easier to understand by others familiar with the same framework. They mean it’s likelier that your work and your colleagues’ work will fit together without errors.
Systematic frameworks chart your path through the underlying platform or framework by packaging the approved-of capabilities and affordances into a readymade system.
Most frameworks operate in the space between. They encode core ideas from the paradigm into a system or subsystem while leaving the rest up to documentation and example. This is useful because many paradigms in software development are only partial solutions to the problems at hand, which means that there is often an element of mixing and matching subsystems required to get a complete system.
The best example of a partially systematic framework would be React, Facebook’s Open Source web development framework. It’s a reactive programming twist (hence the name) on the originally web-based Single-Page-App paradigm. It’s primarily concerned with the view or rendering part of a graphical interface. It can be used with a variety of different state management or business logic subsystems. Its “system”, intentionally, doesn’t provide everything you need to make a web app. This flexibility is a big reason for React’s popularity.
Many of the purely systematic frameworks in web development today have been called meta-frameworks because they take a partially paradigmatic framework, like React, and turn it into an integrated and consistent system— bringing it all the way to the systematic side of the spectrum. They take away your options but simplify the process of using the framework.
This shows us why the paradigmatic-systematic spectrum helps manage software development. On one end of the spectrum, you have flexibility. On the other end, you have productivity.
The more certain you are of a software project’s goals and desired outcomes, the more productivity benefit there is to be had from finding and adopting a fully systematised framework that matches those goals. The more exploratory your project is, the more benefit there is to be had from adopting a partially paradigmatic framework that you can adjust as you discover.
A systematic framework that doesn’t match your goals—a heavyweight framework with a rich set of features when what you need is something high-performance and lightweight, for example—will constantly be fighting you and will lead to disaster. A more paradigmatic framework when you need guide rails leading to a specific outcome is similarly a guaranteed disaster.
Choosing a framework, paradigmatic or systematic, is one of the most important actions you can take to manage any given software project.
Out of the Software Crisis #
Software projects keep failing, not because we don’t have the right team or tools but because our software development system is broken. Out of the Software Crisis is a guide to fixing your software projects with systems-thinking making them more resilient to change and less likely to fail.