Let Your System Have Some Bones

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.

There are some really popular dynamically-typed languages out there, especially in the world of web development — JavaScript, Python, Ruby. These languages let you be very flexible and quick about what you’re building, and often have ways of being somewhat sure-ish of what data you have — the Ruby community talks about “duck typing”, which essentially is about checking what an object can do, rather than what it is (y’know, “if it quacks like a duck”). This is some sort of restriction helping you out, but that can only go so far, because it can be difficult to accurately tell how duck-like the quacking is — if something responds to an open method, does that open do what we think it should?

It’s telling that these languages have some level of type-checking possible: Ruby got a community project in Sorbet, Python introduced type hints in version 3.5, and there’s a superset of JavaScript called TypeScript. These tools let you put type restrictions on your code, determining what some data is at a particular place rather than just what it acts like. (And it’s interesting to mention that TypeScript is a superset of JavaScript, because it has a sort of type compatibility system where one data structure can stand in for another if it’s a superset — if it at least contains the expected shape.)

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.