Why bother using a public framework not of your own design? You have heard that frameworks are heavy and slow; just look at Rasmus’s benchmarks (and my own benchmarking reports before that). Doesn’t it show that the no-framework solution is better?
Besides, you have to spend time learning how to use whatever framework you pick—you might as well spend that time writing your own, right? Or if not a framework, then maybe a way of working that suits you and your team. At least then you know it inside and out.
I assert the apparent short-term strength of “building your own” is more likely a long-term weakness: you may know your way of working inside and out, and maybe the people on your team know it, but nobody else does. That’s a problem for efficiency early on: you have to spend time building that way of working—and it’s a problem for maintenance and training later on. What often turns out to be better is to adopt someone else’s way of working. In a way, it’s like buying into a franchise.
The Business Format Franchise
I won’t go into detailed definitions of business franchises here—just note that I am quoting and paraphrasing exclusively from Gerber’s The E-Myth Revisited. In particular, I’m referring to a “business format” franchise.
When an owner purchases a business format franchise, he gets a sophisticated manual on how to perform every minor detail of how the organization should work. This includes everything from initial setup and equipment purchasing, to hiring and daily operations, to sales and marketing. The owner isn’t part of a larger company; instead, he is an independent operator working with a ruleset shared by everyone else who owns the same franchise. If he follows those rules, he will be able to provide a standardized, consistent product or service to his customers—his business, though independent, will be predictable and reliable (Gerber, page 82-83).
How did this sophisticated operating manual come to be in the first place? A person or team spent a great deal of time building a business—perhaps several businesses—then extracted the rules for its operation and wrote them all down in excruciating detail; this is the Franchise Prototype (Gerber, page 86). There may have been several iterations of that prototype business operation. The franchisor keeps all the “wins” from those iterations and integrates them into the operations manual, and discards the “losses.”
The new franchise operator gets all the benefit of the experience gained from building the Franchise Prototype; so long as he sticks to the rules, the operation of the business should be predictable, and the results repeatable for every customer. The independent franchise operator may not belong to a larger company, but he is part of a larger community, and that has benefits all of its own.
Finally, Gerber notes that to run a successful business, the entrepreneur needs to act as if he is going to sell his business as a franchise prototype. It is the only way the business owner can make the business operate without him being personally involved in every decision. That is, to define and write down every aspect of his operations, so that anyone else can do the same work the same way in a predictable and reliable manner (Gerber, page 96).
The Framework as Franchise
I’m going to use the word “framework” relatively loosely here. For the purposes of this article, I think it’s fair to say that a framework is any collection of tools, techniques and procedures you use on a regular basis to build applications. The framework may be internal to a single organization, or it may be publicly available and generically applicable. It might be a loose collection of code gathered from disjointed sources, or it might be a well-integrated, object-oriented codebase with formal rules for adding new components. Using that definition, almost any regular development practice used by an organization can be called a framework: the framework is the set of implicit and explicit rules for how to build applications. Under this definition, we can see that every development shop does use a framework of some sort.
With that in mind, I think it’s easy to see how we can think of public, generalized framework systems as business format franchises. They are sophisticated rulesets, built over the course of years or more, that address problems common to a specific environment, in a standardized way so that the development process is predictable. Developers choosing a public framework get the benefit of others’ experience and effort in that solution environment. While there are definitely rules for operating within that framework, you usually have a good amount of discretion within those rules for doing the things particular to your application.
A franchise is a well-defined way of working to build an organization. Similarly, a framework is a well-defined way of working to build an application. When you pick a franchise or a framework, you are buying into that way of working. There are lots of ways of working, but the nice thing about public frameworks is that its ruleset can be shared across organizations. While Rasmus might think you should be writing the main stuff in C, that’s much more organization-dependent, and is more difficult to share. Using a public framework lets us all learn from each other and share practices, and improve them.
Even when writing your own framework (which is not advisable these days given the number of publicly available ones), you can adopt what you think are the best practices of others. This is sort of an extension of patterns, to implementations—though you might not be using the same code specifically, the way of working is shared, so you’ll recognize it if you see it anywhere else.
Reducing Cognitive Friction
When you look at frameworks as franchises to ways of working, you realize that using a framework is less about the technical considerations than it is about having an effective and consistent development process for your organization. Among other things, it provides a standardized foundation on which you can base your decisions for application architecture. The decisions and choices made by one developer start to look like the decisions from other developers, because they’re all using the same rule set.
In a way, it’s like coding style standards, but at a higher level. Coding style standards make the code itself look the same regardless of which developer wrote it, and reduces the cognitive friction involved when reviewing and maintaining code from other developers. The style ruleset in and of itself is not as important as the fact that every developer uses exactly the same style. Similarly, the framework in and of itself isn’t as important as the fact that every developer on the team uses it as the major basis for their decision-making—developers who “get” the framework will tend towards the same solutions within that framework, and other developers will recognize why that solution makes sense given the rules of the framework.
Teams and Frameworks
You are using a framework, whether you call it that or not. If you regularly employ a common set of tools and techniques from project to project, that is your framework. It probably suits you very well. When you are working by yourself, your personal framework is perfectly reasonable.
But when you start working on a team of two or three or more developers, your personal way of working isn’t going to be good enough. The other developers will tell you that your framework sucks… and they’ll be right. At first, the solution appears to be that you should teach the team your framework, or else have the team develop their own framework together. This is very appealing; you think you know your own needs better than some framework developers who have never worked in your business, organization, or field of expertise.
But in a way, it’s like the coding style problem: each developer has his own habits and style, and to every other developer it’s highly likely to be “wrong” because the other developer isn’t used to it. You could all collaborate to build a style manual, spending time and effort on it… or you could bypass that work entirely and adopt a publicly available style manual, such as the PEAR coding standard. Adopting a public standard means that not only does your team adhere to a particular ruleset, but so do lots of other developers who are working with the same system. You get the benefit not only of your own team’s work, but of all those other teams as well.
With that in mind, the solution is not to build your own framework from scratch, but to start with one that is already publicly available. Look at this list of public frameworks currently available (and the list is not comprehensive—there are sure to be many more). Look at how similar they are in form and function; they group into three or four major ways of working. By the time you build your own framework from scratch, and learn all the lessons you need to learn in the process of building it, your framework will come to resemble one of the publicly available ones. You can jump past that building process and go straight to the end result, and build on that instead.
If widely varying development shops tend to use the same patterns of application architecture—frequently without knowing that those patterns have been categorized and named—then my bet is that your implementation needs are probably not too different from something that already exists. Nobody likes being told what to do, especially knowledgable workers like developers, but the truth is that your needs (and mine, and everyone else’s) are not as unique as we’d like to think.
Conclusion
Even after reading all this, you may wish to build your own framework anyway, and that’s fine. New business owners have valid reasons for wanting to build a business “their way.” They might have rare and truly unique needs. But as a resource-utilization decision, or as a teamwork and work-process decision, or as a maintainability-and-effectiveness decision, you might be better served to buy into a franchise—that is, to use a publicly available framework as the basis for your way of working.
Comments?
To comment on this Advent post, please see Paul’s blog post. Thanks for reading!
