Friday, 4 October 2013

Prescriptive Vs Descriptive Frameworks

People love to create taxonomies. Just about the first thing that Adam does in Genesis is to name the animals. Classifying and naming things is valuable because it helps us to understand relationships between entities and communicate with other people about them. However, there is a common error where people come to believe that entities that don't fit easily into the taxonomy either don't or shouldn't exist, or solve problems by searching the taxonomy when that's not the best approach.

Design patterns are a great example. They are a very useful vocabulary for explaining code. However, it's usually a mistake to tackle a programming problem by finding the design pattern that best fits and applying that pattern to the problem. Instead, we should always analyze the problem on its own merits, applying all the information we have about the context, and come up with the best solution specific to that problem. (I'm assuming here that we're interested in producing the very best code for a solution, which is true for something like Firefox but not for throw-away code or for projects with a small audience.) But since design patterns are easy to teach, and selecting a design pattern is easier to systematize than finding the best solution ex nihilo, and it's easier to tell your boss that you're using the Fridge Magnet pattern than to explain a bespoke solution, it's easy to see why a lot of people made design patterns their Procrustean bed.

This observation generalizes beyond programming. In areas as diverse as personality tests and politics, there is a drive to describe complex entities with simple categories. Entities that don't fit easily into a single category are implicitly or explicitly discouraged, to disastrous effect. I find it extremely frustrating.

We need to make a clear distinction between descriptive frameworks, which provide vocabulary to talk about common features (often not mutually exclusive), and prescriptive frameworks, which demand that reality be describable with a fixed vocabulary (generally with mutual exclusion). A taxonomic framework is very useful for describing what exists. It should not be used as the search space for solutions to problems, although it may be useful by inspiring you with options you haven't considered.


  1. The problem with "best practices" and "design patterns" and so forth is that people forget that these things aren't a substitute for brainwork, and shouldn't be applied by rote without proper understanding of what they do.

  2. So let's see if I have this straight... frameworks are either descriptive, which is good, or prescriptive, which is bad. Well, except some frameworks might be a little of each, but those are muddled and best ignored. Did I get that right? (j/k)

  3. It seems to me that all frameworks are both descriptive (they give you vocabulary) and prescritive (they expect you to use that vovabulary). Frameworks which have a rich vocabulary are better, of course, but even then, it may be more difficult to express what you want.

    I propose that the real evil is not the prescriptive framework, but premature (and hence inappropriate) choice of framework.

    1. By "prescriptive" I don't mean just "using the vocabulary". I mean what I said in the final paragraph.