Rigidity is death...

Jess Brown -

...flexibility is life. So says my Sensei.

đź“«
This article is from the CYBORG_ newsletter. Enjoy it for free!

When we build systems and tools to help us solve problems, there is a pitfall, especially when you first start.

The first version of the CMS I created at work was exceptionally rigid. There was a field for every bit of text, and you weren’t supposed to be able to break the template design because each field was mapped exactly.

The pitfall came when people discovered they could start hacking—inserting their own (less ideal) HTML code in certain fields. Soon we had a template that broke both the design guidelines and my own system.

The need for flexibility broke the system by inserting bugs, inconsistency, and the maverick attitude.

The problem wasn’t really how it was used, but how it was built, and the behavior was in response to a poorly designed system.

The next version of the CMS offered greater flexibility—being able to create pages using small building blocks and allowing the creator to do whatever they wanted with those pieces.

Systems

Every system has its vulnerabilities, but the more rigid the system, the more likely it will break under use.

This applies in more than just technology. I recently had an eye-opening discussion with a group of academics and theologians about the theories behind Christian religious groups. The more rigid or maximalist a group’s theology/ideology, the more fragile it becomes.

Whether because the ideology becomes too exclusive even to its members or causes objective harm to people, the rigid system becomes a “stumbling block” and loses its value and ability to propel people forward in progress.

Flexibility is life—it’s the evidence of it, but it also supports that life.

The trick is where to build rigidity and where to build flexibility.

Modularity

There’s a design pattern from the programming world that can help us solve this puzzle.

If we think of our systems or whatever we’re building as a stack of LEGO bricks, we can build in “modules” or parts that can moved around in the stack or even used in other stacks.

The design pattern is this: There is only data and behavior, and a function should only handle one of those things.

A function just means one of those “bricks” or one part in your system / process. That part either holds information in some way or it performs some kind of action. By keeping it simple and specialized, you can move that part and reuse that part in many scenarios.

An Example

Project management can seem pretty straightforward until you have to accept requests from people who don’t understand what you do.

I’ve used or set up several request form systems now but I still find that people submit things to me when they should have submitted them to someone else, or they misunderstand how I can help them.

The more rigid and specific the request form, the worse submissions I’ve received.

If, instead, I build in a little flexibility—allowing them to describe what they need and then categorizing it for them—I get better flow within my system.

Modularity helps me with that flexibility, because I can use one "description" field to hold data. The data means something in one context (e.g. a bug report), but it means another thing in a second context (e.g. UX research).

The rigidity simply becomes the insistence of using the form to send me requests, but the flexibility allows that intake to work without frustrating the people using the form and without frustrating me.

A Word from Martha Stewart

I happened to be watching an email marketing conference keynote (Guru, 2023), and whaddaya know? Martha Stewart drops the gem: “Rigidity in business is bad.”

There you have it.

Humanity and flexibility are inseparable. Here are some extra resources and ideas for introducing flexibility or building it in from the start. From your actual body to a code example: