Let Your System Have Some Bones
Using restrictions to support flexibility
Have you ever seen one of those push-button marionette toys? They’re basically a bunch of beads with a string running through them. When the string is tight, it holds all the beads together in shape, and you can see it as a dog, or person, or whatever. But push the button and loosen the string, and the toy collapses.
Constraints are well-regarded for supporting creativity, but I have another consideration to hang on constraints (or restrictions): they provide definition, shape, structure, stability.
There’s a lot to be said about the benefits of flexibility, but take it too far and you’re just floppy and shapeless. If you can theoretically do anything, how can you tell what you should be doing?
Let’s talk about data.
So-called “NoSQL” (sometimes “document”) databases are talked up quite a bit because of their flexibility, their lack of schema. It can be nice and useful to be able to have the data shape customized to each object instead of being a simple rectangle (each row having the same columns), but then you have to figure out things object-by-object instead of knowing what to expect. Because restriction can help you out, these databases tend to have ways to define and enforce schemas, so you know what to expect. (Anecdotally, every project with such a database eventually gets a schema added to it, and not always with the most friendly and useful of tools.)
Relational databases do have schemas built in, and by definition, they’re set up for relationships between tables. At a simple level, you have pre-defined relations and foreign keys. Rails introduced* the concept of a polymorphic association between models, which lets you have a loosier-goosier definition of this relationship. That flexibility can work very nicely, but also makes it harder to know what’s happening with that data. For one thing, it becomes significantly more involved to create a single query to join across relations. Unless, of course, you know what sort of data can be there and what tables you may want to join against — that’s restriction, helping you out.
*: As a formal part of a framework, as much as I’ve been able to determine.
Let’s talk about code.
open method, does that
open do what we think it should?
The best part of these type systems is they let you do this gradually, incrementally — putting the restrictions where they’d be helpful, without needing to have them everywhere. That gradualness is what I really like. To go back to the title metaphor, your system can use bones, but it shouldn’t be entirely bone. It can use a rigid structure to provide support and shape, and some flexible pieces that connect to the rigid structure and operate on it, and maybe a more-flexible skin on top of all of that.
If you’re looking for a team to help you discover the right thing to build and help you build it, get in touch.